Re: [whatwg] Client-side includes proposal
I still get the feeling that this is an element that is being invented for the purpose of being invented and doesn’t solve any existing problem, or resolve any difficult to implement problems that are not already solved in layers below and above HTML. I worry slightly from this and similar proposals that certain parts of the spec will end up being deprecated in the next spec due to lack of use. With regards to instant AJAX for dummies, I struggle to accept that no-one is able to download an already existing javascript library that provides this functionality in a few simple lines. Maybe I've missed something but is there a mandate which sets out the audience HTML5 is trying to satisfy? Do we really need to reinvent the wheel? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonas Sicking Sent: 19 August 2008 03:36 To: Greg Houston Cc: whatwg@lists.whatwg.org; Bill Wallace; João Eiras Subject: Re: [whatwg] Client-side includes proposal Greg Houston wrote: On Mon, Aug 18, 2008 at 4:01 PM, João Eiras [EMAIL PROTECTED] wrote: include src=static-header / include src=user-specific-data / include src=dynamic-daily-content / This is something that would probably not be represented with a new element, because elements are preserved in the DOM tree so they can be accessed and queried. So then you'd have a question: keep includein the dom and allow access to children like an iframe, or replace include entirely ? The answer could be intuitive, but that can open a can of worms. Then you can do all sorts of dynamic manipulation, which would have to be very well specified. I think the way to go would be a processing instruction. The idea is good though ! But I think could be better implemented with a css template like feature. I don't like the idea of a new element. Bye. This seems to be mostly useful for people creating small websites that are afraid of server side scripting languages like PHP, Python and Ruby. That being the case, if something like this is implemented the included content should definitely not be accessed like with an iframe. The elements included should be in the DOM tree of the parent just as if the includes were done server side. Accessing the DOM of an iframe from the parent and vice versa causes people a lot of confusion. I don't think we need to add that level of confusion to the group of users that would most likely use this feature. Also, a bonus of keeping include src=some-content.html / in the DOM, is that changing the source could reload the content of that element. You would have instant AJAX/XHR for dummies. This is basically what i've suggested in a thread some months back. Basically an iframe but that renders as if the inner was included inline. This is far from easy to implement since you have to do layout across several documents. But I think it would be a pretty useful feature to simplify AJAXy pages. If I ever get time I'm going to attempt an implementation in firefox which will hopefully provide experience to build a spec on. / Jonas -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [whatwg] Client-side includes proposal
I can't speak for non Windows/Linux users, but for windows users IIS comes supplied and supports SSI, asp.net php (via a download) etc and with linux you can download apache and a sluth of other http daemons, I see no reason for any html page to require the client to do the inline including of content, as stated previously in this thread the tcp overhead is huge and this would only make it worse in my opinion. M -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shannon Sent: 18 August 2008 18:57 To: Kristof Zelechovski Cc: 'WHAT working group' Subject: Re: [whatwg] Client-side includes proposal Kristof Zelechovski wrote: Client-side includes make a document transformation, something which logically belongs XSLT rather than HTML. And what would the workaround for legacy browsers be? Chris You make good points but last I checked general browser and editor support for XSLT was abysmal. Everyone is saying its on their roadmaps though so maybe it will one day be reliable enough to use. You could go: include src=banner.ihtml h1Banner/h1 /include But this just seems wasteful, pointless and open to abuse. I think a better workaround is that people with legacy browsers download each include file seperately and paste them together in DOS or AmigaOS or whatever system it is that keeps them from installing a modern browser. Of course XSLT has the same legacy issues as do many parts of HTML5. I know the reasoning but at some point the web will have to leave unmaintained software behind or face the same grim reality OpenGL is facing now (can't move forward because a minority want legacy support for 10 year old CAD applications, can't go back because competing protocols are in front on features). I'd like to see the option made available and its use determined by the market as we have always done. If a developer wants to piss-off users by writing a Flash or Silverlight-only website then the ONLY thing we can do is provide an equivalent feature and hope that it does less harm (by virtue of being a truly open standard). The average web developer's mentally is very different from the majority of this list, they won't compromise to do the right thing. If I can do client-side includes in Flash and Silverlight (and I can) then why should HTML be left behind? Anyway, I don't mean for an open discussion on this as I'm sure it's been debated endlessly. I'm just stating my case for going ahead with this feature. Shannon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [whatwg] Active workers when user leaves the page
Hi, Could it not be set that a there is a maximum execution time for any workers that are still active, definable by the browser but with a suggested value of say 1000milliseconds in the spec, any processing that takes longer than this is killed, but gives the option for well built scripts and cleanup processes to run gracefully. Martin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Callahan Sent: 08 August 2008 23:30 To: Jonas Sicking Cc: whatwg Subject: Re: [whatwg] Active workers when user leaves the page On Sat, Aug 9, 2008 at 7:01 AM, Jonas Sicking [EMAIL PROTECTED] wrote: I do want to be agressive with killing workers when the user leaves a page since that makes for better user experience. However I'm also worried about stopping scripts halfway through breaking things and leaving the site with half-finished operations that are stored in databases or localStorage. Aggressive killing of workers without warning when the user navigates away would actually be a good feature. There are various reasons outside anyone's control that a worker might die abruptly. For example, power failure, browser crash, or slow-script style timeout. Applications need to be able to handle those cases, for example by using database transactions or careful use of atomic operations. But that's hard to test and authors probably won't design or test well for those cases since they're relatively uncommon. Expanding abrupt termination scenarios to include navigate-away makes abrupt termination much easier to test, forces authors to design for it early, and will ultimately simplify the application design by reducing the different ways a worker can terminate. This may sound a bit radical, but it's not a new idea. It's a principle sometimes called crash-only software. See e.g. http://www.usenix.org/events/hotos03/tech/full_papers/candea/candea_html/ Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6] -- This message has been scanned for viruses and dangerous content by MailScanner http://www.mailscanner.info/ , and is believed to be clean.
