[whatwg] Client-side includes proposal
The discussion on seamless iframes reminded me of something I've felt was missing from HTML - an equivalent client functionality to server-side includes as provided by PHP, Coldfusion and SSI. In server-side includes the document generated from parts appears as a single entity rather than nested frames. In other words the source code seen by the UA is indistiguishable from a non-frames HTML page in every way. iframes are good for some things but they can be really messy when you're trying to build a single seamless page with shared styles and scripts from multiple files. It makes code reuse a real pain without relying on a server-side dynamic language. The seamless iframes proposal doesn't really address this well because you'll have more than one HTML and BODY element causing strange behaviour or complex exceptions with seamless CSS. The other issue with iframes is that for many page snippets the concept of a title, meta tags and other headers don't make sense or simply repeat what was in the main document. More often than not the head section is meaningless yet must still be included for the frame to be well-formed or indexed by spiders. The proposal would work like this: --- Master Document --- html head titleInclude Example/title meta name=includes content=allow include src=global_head.ihtml /head body include src=header.ihtml include src=http://www.pagelets.com/foo.ihtml; include src=footer.ihtml /body /html --- Header.html --- div id=header h1Header/h1 /div With this proposal seamless CSS would work perfectly because child selectors won't see an intervening body element between sections. Includes should allow any html segments except the initial doctype and head (for reasons explained below) and should allow start and end tags to be split across includes. Only tags themselves may not contain an include (eg, body include src=body_attributes.ihtml). Many server-side includes allow this but it breaks the syntax of HTML/XML. Includes must respect their own HTTP headers but inherit all other properties, styles and scripts from the surrounding page. If an include is not set to expire immediately the browser should reuse it from memory, otherwise it should retreive it once for each include. Each behaviour has its own merits depending on the application. The standard would recommend (but not require) includes to use an .ihtml extension. This will make it easier for authors, UAs and logging systems to distinguish partial and complete pages (ie, not count includes towards page views in a stats package). UAs or UA extensions like the Mozilla-based Web Developer should allow the user to view the actual source and the final source (with all includes substituted). HTTP 1.1 pipelining should remove any performance concerns that includes would have over traditional SSI since the retrieval process only requires the sending of a few more bytes of request and response headers. In some ways it is actually better because UAs and proxies can cache the static includes and only fetch the dynamic parts. The only real issue with this proposal is security for untrusted content like myspace profiles. Traditional sanitisers would be unfamiliar with include and may allow it through, providing a backdoor for malicious code. For this reason it is necessary that includes be opt-in. The simplest mechanism is to use a meta tag in the head of the master document: meta name=includes content=allow I would consider any content system that allowed untrusted users to write their own head tags to be incurable insecure; however this requirement should ensure that the majority do not suddenly experience a wave of new exploits in HTML5 browsers. Shannon
Re: [whatwg] overflow of seamless iframes
On Mon, 18 Aug 2008, Robert O'Callahan wrote: On Mon, Aug 18, 2008 at 4:40 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 18 Aug 2008, Robert O'Callahan wrote: Note that the default width and height are adjusted for seamless iframes to match the width that the element would have if it was a non-replaced block-level element with 'width: auto', and the height of the bounding box around the content rendered in the iframe at its current width, respectively. The bounding box is a bit ambiguous. If the content overflows vertically above the iframe's viewport, does that contribute to the height of the bounding box? As far as I can tell there is no ambiguity to the concept of the bounding box of the content in the canvas, especially given the way the initial containing block is forced to zero height. What's the answer to my question then? Should I have been able to derive it somehow? I don't understand the question. How does the viewport affect the bounding box? For greater seamlessness, I'd prefer to make the intrinsic height be the height of the iframe's root element. Why would that be more seamless? Surely that would be less seamless if there were things like negative margins, since then you'd have unsightly scrollbars appearing. You mean the scrollbars associated with the iframe viewport? Right. I just thought of another problem with allowing the contents of a seamless iframe to overflow outside the iframe box. One of the main uses for this will be to sandbox blog comments, using the yet-to-be-defined doc= attribute, as in: iframe doc=!DOCTYPE HTMLpYou suck seamless sandbox=allow-same-origin/iframe If we allow the contents to flow out of the box, then we also allow blog comments to start overlapping other content on the page. The current definition is intended to be really easy to implement without needing any changes to the CSS model. I think that's a good goal, but we also want it to be reasonably seamless. I'm concerned about the use case of very wide content in the iframe (i.e. content overflowing the root element horizontally); for example a forum with many wide messages, each of which is a seamless iframe. Right now it seems the choices are to either have a horizontal scrollbar in each message or clip each message horizontally, there's no way to make it work like a forum page. The way forum pages work now is that the content ends up screwing up the rest of the page, so I think that's a good thing. :-) People work around this now by forcing line break opportunities to exist in long URLs, etc, or by setting overflow:auto on user-submitted content. Actually I'm not 100% sure you mean by the width that the element would have if it was a non-replaced block-level element with 'width: auto'. You mean if it was such a block-level element containing the root element of the iframe's document? I guess if the element is itself in an element that is shrink-wrapping, the current spec is underdefined. I'm not sure what width would be the right width at that point. Zero? The narrowest width for which increasing the width by one pixel doesn't decrease the height or decrease the number of line breaks? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Client-side includes proposal
On Mon, 18 Aug 2008, Shannon wrote: The discussion on seamless iframes reminded me of something I've felt was missing from HTML - an equivalent client functionality to server-side includes as provided by PHP, Coldfusion and SSI. In server-side includes the document generated from parts appears as a single entity rather than nested frames. In other words the source code seen by the UA is indistiguishable from a non-frames HTML page in every way. What advantage does this have over server-side includes? The iframe doc= seamless idea has the advantage of not blocking rendering, which a client-side parsing-level include would. I don't really see what the advantage of a client-side parsing-level include would be. The other issue with iframes is that for many page snippets the concept of a title, meta tags and other headers don't make sense or simply repeat what was in the main document. More often than not the head section is meaningless yet must still be included for the frame to be well-formed or indexed by spiders. Yeah, I've been considering making the title element optional for documents that aren't meant to be navigated to directly, like includes. HTTP 1.1 pipelining should remove any performance concerns that includes would have over traditional SSI since the retrieval process only requires the sending of a few more bytes of request and response headers. A TCP round-trip is very expensive. A client-side parsing-level include would mean that the parser would have to stop while a complete round-trip is performed. There's really no way to get around that short of making it a higher-level construct like iframe seamless. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Client-side includes proposal
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 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shannon Sent: Monday, August 18, 2008 8:34 AM To: WHAT working group Subject: [whatwg] Client-side includes proposal The proposal would work like this: --- Master Document --- html head titleInclude Example/title meta name=includes content=allow include src=global_head.ihtml /head body include src=header.ihtml include src=http://www.pagelets.com/foo.ihtml; include src=footer.ihtml /body /html --- Header.html --- div id=header h1Header/h1 /div
Re: [whatwg] overflow of seamless iframes
On Mon, Aug 18, 2008 at 6:45 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 18 Aug 2008, Robert O'Callahan wrote: On Mon, Aug 18, 2008 at 4:40 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 18 Aug 2008, Robert O'Callahan wrote: Note that the default width and height are adjusted for seamless iframes to match the width that the element would have if it was a non-replaced block-level element with 'width: auto', and the height of the bounding box around the content rendered in the iframe at its current width, respectively. The bounding box is a bit ambiguous. If the content overflows vertically above the iframe's viewport, does that contribute to the height of the bounding box? As far as I can tell there is no ambiguity to the concept of the bounding box of the content in the canvas, especially given the way the initial containing block is forced to zero height. What's the answer to my question then? Should I have been able to derive it somehow? I don't understand the question. How does the viewport affect the bounding box? Suppose the iframe's document is body style=position:relative; top:-100px; height:500px; background:yellow;/body What's the height of the bounding box? 400px or 500px? I just thought of another problem with allowing the contents of a seamless iframe to overflow outside the iframe box. One of the main uses for this will be to sandbox blog comments, using the yet-to-be-defined doc= attribute, as in: iframe doc=!DOCTYPE HTMLpYou suck seamless sandbox=allow-same-origin/iframe If we allow the contents to flow out of the box, then we also allow blog comments to start overlapping other content on the page. Yeah, although setting overflow:hidden on the iframe could be used to prevent that. I'm concerned about the use case of very wide content in the iframe (i.e. content overflowing the root element horizontally); for example a forum with many wide messages, each of which is a seamless iframe. Right now it seems the choices are to either have a horizontal scrollbar in each message or clip each message horizontally, there's no way to make it work like a forum page. The way forum pages work now is that the content ends up screwing up the rest of the page, so I think that's a good thing. :-) People work around this now by forcing line break opportunities to exist in long URLs, etc, or by setting overflow:auto on user-submitted content. Yes, although it would be nice to offer authors a choice. Oh well, I suppose it doesn't matter too much. 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]
[whatwg] video implicitly invoke the load() method
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#load There are a number of conditions for media elements where the user agent must implicitly invoke the load() method on the media element as soon as all other scripts have finished executing: * a source element is inserted into a media element that is already in a document and whose networkState is in the EMPTY state * the src attribute of a media element that is already in a document and whose networkState is in the EMPTY state is added, changed, or removed * a media element whose networkState has the value EMPTY is inserted into a document Now consider this markup video src=foo/video with this script dynamically changing the sources video = document.getElementById(video); video.removeAttribute(src); // implicit delayed load source = document.createElement(source); source.src = bar; source.media = projection; video.appendChild(source); // implicit delayed load source = document.createElement(source); source.src = baz; source.media = screen; video.appendChild(source); // implicit delayed load video.play() // i want to play now! play() will call load() before returning, so after this has finished there shouldn't be any need to load() any more. However, there is no less than 3 calls to load() waiting. Playback will begin, but will stop as soon as the first of those delayed loads are invoked. I believe that the spec actually may allow the N implicit loads to be treated as 1, but at the very least there must be that 1, which is still too many in this case. I doubt many authors will realize all the things which may cause an implicit load, so I think the spec needs to allow for this to be made simpler (from the script author's point of view). More importantly, there's absolutely no need to implicitly call load once its been explicitly called once. I would suggest the following solution: If when the time comes to invoke the load() method it has already been invoked (directly or via another implicit invocation triggered by the same script) then don't call it again. Comments? I'm not sure exactly how to change the spec, but if we agree that this needs fixing we can come back to that. -- Philip Jägenstedt Opera Software
Re: [whatwg] Client-side includes proposal
Ian Hickson wrote: On Mon, 18 Aug 2008, Shannon wrote: The discussion on seamless iframes reminded me of something I've felt was missing from HTML - an equivalent client functionality to server-side includes as provided by PHP, Coldfusion and SSI. What advantage does this have over server-side includes? The iframe doc= seamless idea has the advantage of not blocking rendering, which a client-side parsing-level include would. I don't really see what the advantage of a client-side parsing-level include would be. Cost. SSI of any description generally puts you on a business hosting plan with a cost increase of up to 10x. Client-side includes only require static page serving which can also be beneficial where the server is a device (like a router interface). Availability. As far as I can tell SSI is only available on Apache and later versions of IIS. This may be a market majority but when you consider the number of devices and home servers coming onto the market with basic web interfaces the actual availability of SSI may be lower than you'd expect. Security. Availability is reduced even further by ISP and organisations that flat-out refuse to support SSI due to security and support concerns. Reuse. SSI follows no agreed set of rules and therefore may require code changes when changing hosting provider. Some systems provide extensions that authors may assume is part of a standard, but aren't. We have an opportunity to define a simpler and more reliable interface that is independant of any server configuration. Speed. Concerns about speed are generally only valid for the first page on the first visit to a site. Subsequent pages can be much faster than SSI and even static html since common banners and footers can be cached seperately - requiring only a unique content download. This is less trivial than it sounds since global drop-down menus, ad frames, tracking code, overlays and embedded JS and CSS often account for a vast majority of the source code. Flexibility. It's hard to tell because the seamless proposal is vague but from what I can tell there are a lot of things a seamless iframe is not seamless about. For instance can absolutely positioned items be positioned relative to the enclosing document? Do child and adjacent selectors work across the iframe boundary? Will IE give up its behaviour of placing iframes above the document regardless of z-index? Includes don't have any of these issues because they are treated as part of the document, not as a special case. Even with these advantages I do not believe it is an either/or case. seamless iframes serve a purpose too and I do not want to see them dropped from the spec. I would however like to see more clarity in the spec as to how they interact with scripts and styles (especially adjacency selectors) in the master document and neighbouring seamless frames. HTTP 1.1 pipelining should remove any performance concerns that includes would have over traditional SSI since the retrieval process only requires the sending of a few more bytes of request and response headers. A TCP round-trip is very expensive. A client-side parsing-level include would mean that the parser would have to stop while a complete round-trip is performed. There's really no way to get around that short of making it a higher-level construct like iframe seamless. There is actually an easy solution for this, though it is less flexible than my original proposal. The solution is to require each include to be balanced (equal number of open and close tags) so the surrounding block is guaranteed to be a single node. Anything left open is forcefully closed (as when reaching /body with open blocks). In other words: div id=content style=min-height:500px include src=content.ihtml /div!-- always closes content -- Since we know content is a closed block we can draw in a transparent placeholder and continue rendering the outer document as we do with img, video, iframes and embed. Once the true dimensions are known the renderer can repaint as it does with table cells and other auto sizing. This will often improve the readability of documents on slower connections since the top third of source code is usually concerned with banners, menus, search-bars and other cruft not directly relevant to the content the user wants to view and this is exactly the stuff you would want to put in an include to begin with. If it renders last then all the better. Shannon
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
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] Client-side includes proposal
It is only expensive if the client needs to do the client side include each time - however, if the page re-uses parts all the time, then parts of the page can be cached either in a proxy or directly client side, and that can make it faster as well as reducing server load. Consider including 3-4 components: include src=static-header / include src=user-specific-data / include src=dynamic-daily-content / This type of page needs to be read at least a couple of times for each client for it to be faster, but there are lots of clients like that. HOWEVER - how about just using the xlink design and making it part of the html standard (allowing HTML fragments to be included, not just XML). That has client side includes, and also supports client side replacement of components based on clicking a URL/button/object. Supporting xlink in html consistently would allow most of the current JavaScript based applications to be replaced with JavaScript free applications, and that would make many of them much safer, and is reasonably efficient. 2008/8/18 Martin Ellis [EMAIL PROTECTED] 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] Client-side includes proposal
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.
Re: [whatwg] video implicitly invoke the load() method
On Mon, 18 Aug 2008, Philip J�genstedt wrote: Now consider this markup video src=foo/video with this script dynamically changing the sources video = document.getElementById(video); video.removeAttribute(src); // implicit delayed load source = document.createElement(source); source.src = bar; source.media = projection; video.appendChild(source); // implicit delayed load source = document.createElement(source); source.src = baz; source.media = screen; video.appendChild(source); // implicit delayed load video.play() // i want to play now! play() will call load() before returning, so after this has finished there shouldn't be any need to load() any more. However, there is no less than 3 calls to load() waiting. Playback will begin, but will stop as soon as the first of those delayed loads are invoked. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Client-side includes proposal
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. - Greg
Re: [whatwg] Client-side includes proposal
On Tue, 19 Aug 2008, Shannon wrote: What advantage does this have over server-side includes? Cost. SSI of any description generally puts you on a business hosting plan with a cost increase of up to 10x. Client-side includes only require static page serving which can also be beneficial where the server is a device (like a router interface). Availability. As far as I can tell SSI is only available on Apache and later versions of IIS. This may be a market majority but when you consider the number of devices and home servers coming onto the market with basic web interfaces the actual availability of SSI may be lower than you'd expect. Security. Availability is reduced even further by ISP and organisations that flat-out refuse to support SSI due to security and support concerns. All three of the above basically boil down to the same thing -- there are hosting providers that don't provide the simplest of features. That's certainly true, but there are also hosting providers that provide these features for very cheap (e.g. $120/year or less) that provide all this and more, so I don't buy this argument. If you're having trouble finding one, contact me privately and I can give you a coupon code for one. Reuse. SSI follows no agreed set of rules and therefore may require code changes when changing hosting provider. Some systems provide extensions that authors may assume is part of a standard, but aren't. We have an opportunity to define a simpler and more reliable interface that is independant of any server configuration. If it's just a static site, then you can just pre-generate the pages and upload the completed pages, so there's no dependency on the server. This, incidentally, also works when the server-side hosting provider doesn't support SSIs at all. If it's not a static site, then the SSIs are going to be the least of your problems when you change to a different server. Speed. Concerns about speed are generally only valid for the first page on the first visit to a site. Subsequent pages can be much faster than SSI and even static html since common banners and footers can be cached seperately - requiring only a unique content download. This is less trivial than it sounds since global drop-down menus, ad frames, tracking code, overlays and embedded JS and CSS often account for a vast majority of the source code. We're talking about such a small amount of data here that the latency far outweighs the bandwidth cost on most connections. Given that you still have to do an If-Modified-Since check, you don't really gain anything here. If we did want to optimise for small parts of the content being common over multiple pages, we should investigate dictionary-based compression with site-specific dictionaries. That would get us much, much better performance than cached CSIs. Flexibility. It's hard to tell because the seamless proposal is vague but from what I can tell there are a lot of things a seamless iframe is not seamless about. For instance can absolutely positioned items be positioned relative to the enclosing document? Do child and adjacent selectors work across the iframe boundary? Will IE give up its behaviour of placing iframes above the document regardless of z-index? Includes don't have any of these issues because they are treated as part of the document, not as a special case. This isn't an argument over SSIs. I agree that for inclusions, the iframe seamless feature isn't optimal. It was not designed for that, it was meant for including sandboxed blog comments and the like. A TCP round-trip is very expensive. A client-side parsing-level include would mean that the parser would have to stop while a complete round-trip is performed. There's really no way to get around that short of making it a higher-level construct like iframe seamless. There is actually an easy solution for this, though it is less flexible than my original proposal. The solution is to require each include to be balanced (equal number of open and close tags) so the surrounding block is guaranteed to be a single node. Anything left open is forcefully closed (as when reaching /body with open blocks). In other words: div id=content style=min-height:500px include src=content.ihtml /div!-- always closes content -- What do you do when the CSIed page includes script that manipulates content after the include? Now you have a race condition. This is just as bad as blocking, if not worse, since it's now unpredictable. Anyway in conclusion I don't understand what CSIs give us that is actually worth the massive amounts of effort they require. Just generate your pages server-side or upload them to your server pre-generated. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer.
[whatwg] Using video as a source for canvas.drawImage
Thanks to Anne for pointing this out... We've implemented using video elements as an image source in canvas.drawImage: https://bugzilla.mozilla.org/show_bug.cgi?id=448674 The extension is very obvious. Unlike animated images, which always draw the first or poster frame, we draw the current frame of the video. This lets you do things like make a thumbnail timeline. It'd be nice to have this in the spec. 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]
Re: [whatwg] Client-side includes proposal
On Mon, 18 Aug 2008, Bill Wallace wrote: It is only expensive if the client needs to do the client side include each time - however, if the page re-uses parts all the time, then parts of the page can be cached either in a proxy or directly client side, and that can make it faster as well as reducing server load. Consider including 3-4 components: include src=static-header / include src=user-specific-data / include src=dynamic-daily-content / This type of page needs to be read at least a couple of times for each client for it to be faster, but there are lots of clients like that. This still ends up being expensive due to the round-trip cost of checking if the resource has changed or not, even if the resource itself isn't transferred. It's cheaper to just include the content. If we wanted to optimise this case, we should look into dictionary-based compression. HOWEVER - how about just using the xlink design and making it part of the html standard (allowing HTML fragments to be included, not just XML). That has client side includes, and also supports client side replacement of components based on clicking a URL/button/object. Supporting xlink in html consistently would allow most of the current JavaScript based applications to be replaced with JavaScript free applications, and that would make many of them much safer, and is reasonably efficient. I assume you mean XInclude, not XLink (XLink is a disaster). Certainly if people want to use XInclude with XHTML there's nothing in the HTML5 spec that stops it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Using video as a source for canvas.drawImage
Nice feature! That will be quite useful. -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ On Mon, Aug 18, 2008 at 2:45 PM, Robert O'Callahan [EMAIL PROTECTED]wrote: Thanks to Anne for pointing this out... We've implemented using video elements as an image source in canvas.drawImage: https://bugzilla.mozilla.org/show_bug.cgi?id=448674 The extension is very obvious. Unlike animated images, which always draw the first or poster frame, we draw the current frame of the video. This lets you do things like make a thumbnail timeline. It'd be nice to have this in the spec. 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]
Re: [whatwg] Using video as a source for canvas.drawImage
Cool -- I wonder though if it would be better if it were placed in a different method, drawFrame or something (very much an up in the air sort of question) One other thing that I would consider would be requiring the frame# to be specified explicitly as that would make things like chapter previews (or whatever) work in a way that is perhaps cleaner. Otherwise you have to record the current location in the video stream, then scan to each location you want to blit, draw, and then return to the original position. Which could easily result in weird visual behaviour for the user (as the video element flickers a few random frames while you do your previews or whatever). Just my 2c. --Oliver On Aug 18, 2008, at 2:45 PM, Robert O'Callahan wrote: Thanks to Anne for pointing this out... We've implemented using video elements as an image source in canvas.drawImage: https://bugzilla.mozilla.org/show_bug.cgi?id=448674 The extension is very obvious. Unlike animated images, which always draw the first or poster frame, we draw the current frame of the video. This lets you do things like make a thumbnail timeline. It'd be nice to have this in the spec. 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]
Re: [whatwg] Using video as a source for canvas.drawImage
any suggestions as to what the equivalent would be for mapping audio tracks to filters defined elsewhere ? On Mon, Aug 18, 2008 at 2:45 PM, Robert O'Callahan [EMAIL PROTECTED]wrote: Thanks to Anne for pointing this out... We've implemented using video elements as an image source in canvas.drawImage: https://bugzilla.mozilla.org/show_bug.cgi?id=448674 The extension is very obvious. Unlike animated images, which always draw the first or poster frame, we draw the current frame of the video. This lets you do things like make a thumbnail timeline. It'd be nice to have this in the spec. 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]
Re: [whatwg] overflow of seamless iframes
On Mon, 18 Aug 2008, Robert O'Callahan wrote:
Suppose the iframe's document is
body style=position:relative; top:-100px; height:500px;
background:yellow;/body
What's the height of the bounding box? 400px or 500px?
500px.
If we allow the contents to flow out of the box, then we also allow
blog comments to start overlapping other content on the page.
Yeah, although setting overflow:hidden on the iframe could be used to
prevent that.
Fair enough. In that case I'd rather we had this in the UA stylesheet:
iframe[seamless][sandbox] { overflow: hidden ! important; }
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Using video as a source for canvas.drawImage
On Tue, Aug 19, 2008 at 11:24 AM, Oliver Hunt [EMAIL PROTECTED] wrote: Cool -- I wonder though if it would be better if it were placed in a different method, drawFrame or something (very much an up in the air sort of question) drawImage is already overloaded, so why not carry on with that, unless we change the API as you suggest below. One other thing that I would consider would be requiring the frame# to be specified explicitly as that would make things like chapter previews (or whatever) work in a way that is perhaps cleaner. Otherwise you have to record the current location in the video stream, then scan to each location you want to blit, draw, and then return to the original position. Which could easily result in weird visual behaviour for the user (as the video element flickers a few random frames while you do your previews or whatever). AFAIK we'd basically have to implement that by creating a second video stream, seeking it and then capturing the frame, and you really don't want to do that synchronously! Then we'd want to cache that stream so that another drawFrame with a nearby frame index was efficient ... ick. So I suggest not offering that API. Authors can always use a second, hidden video element to achieve the same effect. 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]
Re: [whatwg] overflow of seamless iframes
On Tue, Aug 19, 2008 at 12:21 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Mon, 18 Aug 2008, Robert O'Callahan wrote:
Suppose the iframe's document is
body style=position:relative; top:-100px; height:500px;
background:yellow;/body
What's the height of the bounding box? 400px or 500px?
500px.
That's a little weird since only 400px of content will be displayed, but OK
as long as it's clear :-).
If we allow the contents to flow out of the box, then we also allow
blog comments to start overlapping other content on the page.
Yeah, although setting overflow:hidden on the iframe could be used to
prevent that.
Fair enough. In that case I'd rather we had this in the UA stylesheet:
iframe[seamless][sandbox] { overflow: hidden ! important; }
I'd suggest having that except without !important.
But never mind about this issue anyway. I think we can live without it.
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]
Re: [whatwg] overflow of seamless iframes
On Tue, 19 Aug 2008, Robert O'Callahan wrote: But never mind about this issue anyway. I think we can live without it. Ok. As far as the spec goes, the current text is mostly a strawman proposal. I'm hoping to tweak it based on implementation experience. So, what I recommend is that you implement what you think is best, based on what the spec says, and then send us a report with your experience, suggesting changes to the spec as appropriate. The key use case that I want to make sure we address as far as seamless goes is the blog comments thing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] overflow of seamless iframes
On Tue, Aug 19, 2008 at 1:05 PM, Robert O'Callahan [EMAIL PROTECTED]wrote: On Tue, Aug 19, 2008 at 12:21 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 18 Aug 2008, Robert O'Callahan wrote: Suppose the iframe's document is body style=position:relative; top:-100px; height:500px; background:yellow;/body What's the height of the bounding box? 400px or 500px? 500px. That's a little weird since only 400px of content will be displayed, but OK as long as it's clear :-). Hmm ... does the bounding box take into account scroll positions? Because if it does, then scrolling in the iframe's document can change the intrinsic height of the iframe (for example if there's also fixed-pos content in the iframe). That doesn't sound good. 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]
Re: [whatwg] Using video as a source for canvas.drawImage
On Aug 18, 2008, at 5:58 PM, Robert O'Callahan wrote: On Tue, Aug 19, 2008 at 11:24 AM, Oliver Hunt [EMAIL PROTECTED] wrote: Cool -- I wonder though if it would be better if it were placed in a different method, drawFrame or something (very much an up in the air sort of question) drawImage is already overloaded, so why not carry on with that, unless we change the API as you suggest below. I'm not sure that drawImage overloading was a good idea in the first place *but* canvas and image are fairly similar in both image-like, whereas video is quite clearly different. I was also thinking it would work better given the additional frame argument, however... AFAIK we'd basically have to implement that by creating a second video stream, seeking it and then capturing the frame, and you really don't want to do that synchronously! Then we'd want to cache that stream so that another drawFrame with a nearby frame index was efficient ... ick. So I suggest not offering that API. Authors can always use a second, hidden video element to achieve the same effect. ... I had failed to consider streaming content (where random seeking may not be possible) :-/ I still think it would be useful to be able to specify an exact frame, but as you say it may not be really feasible --Oliver
Re: [whatwg] Client-side includes proposal
Ian Hickson wrote: All three of the above basically boil down to the same thing -- there are hosting providers that don't provide the simplest of features. That's certainly true, but there are also hosting providers that provide these features for very cheap (e.g. $120/year or less) that provide all this and more, so I don't buy this argument. If you're having trouble finding one, contact me privately and I can give you a coupon code for one. Thank you but I have my own servers. You make a pretty big assumption here about the usage model of the Internet being corporate + ISP. You ignore: * Web applications and HTML documentation on the local filesystem. * Local testing in WYSIWYG editors. * Autorun frontends on CDROM that are typically employed by magazine coverdiscs. * Embedded servers in storage devices, media centers, routers and other gadgets. * Minimalist HTTP servers for simple usage, websocket tunnels or high load services. * Users taking advantage of free hosting services with limited features (like Sourceforge or Geocities). * Charities and OSS groups with better things to spend their money on than hosting package upgrades. * Companies like many in the building and equipment hire industries that spent $500 on a website and call it expensive. Far from being a small minority these groups and applications possibly make up the majority of HTML content after blogs. If it's just a static site, then you can just pre-generate the pages and upload the completed pages, so there's no dependency on the server. This, incidentally, also works when the server-side hosting provider doesn't support SSIs at all. If it's not a static site, then the SSIs are going to be the least of your problems when you change to a different server. I assume that by pre-generated you're referring to Dreamweaver/WebObjects templates rather than copy-and-paste. I find these irritating as quite often you are given one format but require another (as a FOSS user I can't/won't use Dreamweaver). Some of the best editors don't have any kind of template support and when they do it's typically native to the application. Sometimes they're even native to an installation (you can't export your templates). These things are bad for the web without some kind of accepted open specification. CSI could be that specification. Speed. Concerns about speed are generally only valid for the first page on the first visit to a site. Subsequent pages can be much faster than SSI and even static html since common banners and footers can be cached seperately - requiring only a unique content download. This is less trivial than it sounds since global drop-down menus, ad frames, tracking code, overlays and embedded JS and CSS often account for a vast majority of the source code. We're talking about such a small amount of data here that the latency far outweighs the bandwidth cost on most connections. Given that you still have to do an If-Modified-Since check, you don't really gain anything here. I'm not sure where you get your statistics but these claims don't match my direct experience. In the typical case a web page is heavily dependant on included content such as CSS files, images, plugins and other non-embedded elements. Even geek sites like orielly.com and slashdot are not immune. According to websiteoptimization.com the orielly home page has 60 external objects. Many common sites are even worse. Your claim that adding HTML includes will have any noticeable affect on overall page loading times needs more analysis. orielly.com: Total HTML: 5 Total HTML Images: 31 Total CSS Images: 14 Total Images: 45 Total Scripts: 7 Total CSS imports: 1 Total Frames: 0 Total Iframes: 4 report: http://www.websiteoptimization.com/services/analyze/wso.php?url=http://oreilly.com/ If we did want to optimise for small parts of the content being common over multiple pages, we should investigate dictionary-based compression with site-specific dictionaries. That would get us much, much better performance than cached CSIs. I like this idea, but it isn't an alternative to CSI from a designers perspective nor is it likely to have significant gains over current gzip implementations. This isn't an argument over SSIs. I agree that for inclusions, the iframe seamless feature isn't optimal. It was not designed for that, it was meant for including sandboxed blog comments and the like. I absolutely agree that iframes aren't an alternative to CSI, not vice-versa. A TCP round-trip is very expensive. A client-side parsing-level include would mean that the parser would have to stop while a complete round-trip is performed. There's really no way to get around that short of making it a higher-level construct like iframe seamless. There is actually an easy solution for this, though it is less flexible than my original proposal. The solution is to require each include
Re: [whatwg] Client-side includes proposal
On Tue, 19 Aug 2008, Shannon wrote: You make a pretty big assumption here about the usage model of the Internet being corporate + ISP. You ignore: * Local testing in WYSIWYG editors. WYSIWYG editors are quite capable of implementing a model whereby pages are merged before being previewed, and are merged when published, removing the need for any post-publication inclusion mechanism. * Embedded servers in storage devices, media centers, routers and other gadgets. * Minimalist HTTP servers for simple usage, websocket tunnels or high load services. * Users taking advantage of free hosting services with limited features (like Sourceforge or Geocities). * Charities and OSS groups with better things to spend their money on than hosting package upgrades. * Companies like many in the building and equipment hire industries that spent $500 on a website and call it expensive. In all of these cases, it is quite feasible to just pre-generate the documents with the includes directly in the content. * Web applications and HTML documentation on the local filesystem. * Autorun frontends on CDROM that are typically employed by magazine coverdiscs. These aren't part of the use cases I am considering. I assume that by pre-generated you're referring to Dreamweaver/WebObjects templates rather than copy-and-paste. I was really thinking of C++ preprocessor includes, but any mechanism would be fine, sure. I find these irritating as quite often you are given one format but require another (as a FOSS user I can't/won't use Dreamweaver). I usually just roll my own using Perl, it's like one or two lines depending on what you want. We're talking about such a small amount of data here that the latency far outweighs the bandwidth cost on most connections. Given that you still have to do an If-Modified-Since check, you don't really gain anything here. I'm not sure where you get your statistics but these claims don't match my direct experience. In the typical case a web page is heavily dependant on included content such as CSS files, images, plugins and other non-embedded elements. Even geek sites like orielly.com and slashdot are not immune. According to websiteoptimization.com the orielly home page has 60 external objects. Many common sites are even worse. Your claim that adding HTML includes will have any noticeable affect on overall page loading times needs more analysis. Most content doesn't require blocking. Those that require blocking (like scripts) are a massive problem. Just ask any browser vendor. Safari even ends up running a second tokeniser in parallel just to try to help this. div id=content style=min-height:500px include src=content.ihtml /div!-- always closes content -- What do you do when the CSIed page includes script that manipulates content after the include? Now you have a race condition. This is just as bad as blocking, if not worse, since it's now unpredictable. You do the same thing you always have when external JS or inter-page requests raise the same issue. External (blocking) JS is a disaster. We don't want to be adding more features like it. We're still trying to get out of the problems blocking scripts added. Anyway in conclusion I don't understand what CSIs give us that is actually worth the massive amounts of effort they require. Just generate your pages server-side or upload them to your server pre-generated. As a developer I tell you this is not really a good option, and I disagree with your claim of massive effort. It is a fairly straightforward feature as they go. Embedded SQL is a massive effort, WebWorkers is massive effort, client-side includes is quite trivial, relatively speaking. Certainly worth further investigation in light of its obvious benefits. Providing client-side includes in an efficient manner is on the same kind of scale as the other features you mention, but it doesn't have anywhere near the same level of benefit. IMHO. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
