[whatwg] Client-side includes proposal

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'