[whatwg] Client-side includes proposal
shannon at arc.net.au
Mon Aug 18 10:18:50 PDT 2008
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
> 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
> 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">
</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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg