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