[whatwg] Client-side includes proposal
ian at hixie.ch
Mon Aug 18 14:43:39 PDT 2008
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
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg