[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080819/4bb2de70/attachment.htm>

Received on Monday, 18 August 2008 10:18:50 UTC