[whatwg] Client-side includes proposal

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 
> way.

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 
> 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>.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'