[whatwg] Client-side includes proposal

On Mon, 18 Aug 2008, Bill Wallace wrote:
>
> It is only expensive if the client needs to do the client side include 
> each time - however, if the page re-uses parts all the time, then parts 
> of the page can be cached either in a proxy or directly client side, and 
> that can make it faster as well as reducing server load. Consider 
> including 3-4 components:
> 
> <include src="static-header" />
> <include src="user-specific-data" />
> <include src="dynamic-daily-content" />
> 
> This type of page needs to be read at least a couple of times for each 
> client for it to be faster, but there are lots of clients like that.

This still ends up being expensive due to the round-trip cost of checking 
if the resource has changed or not, even if the resource itself isn't 
transferred. It's cheaper to just include the content. If we wanted to 
optimise this case, we should look into dictionary-based compression.


> HOWEVER - how about just using the xlink design and making it part of 
> the html standard (allowing HTML fragments to be included, not just 
> XML).  That has client side includes, and also supports client side 
> replacement of components based on clicking a URL/button/object.  
> Supporting xlink in html consistently would allow most of the current 
> JavaScript based applications to be replaced with JavaScript free 
> applications, and that would make many of them much safer, and is 
> reasonably efficient.

I assume you mean XInclude, not XLink (XLink is a disaster). Certainly if 
people want to use XInclude with XHTML there's nothing in the HTML5 spec 
that stops it.

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

Received on Monday, 18 August 2008 14:46:15 UTC