[whatwg] Client-side includes proposal

Ian Hickson wrote:
> 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.
>
>   
Thank you but I have my own servers. You make a pretty big assumption 
here about the usage model of the Internet being corporate + ISP. You 
ignore:

* Web applications and HTML documentation on the local filesystem.
* Local testing in WYSIWYG editors.
* Autorun frontends on CDROM that are typically employed by magazine 
coverdiscs.
* Embedded servers in storage devices, media centers, routers and other 
gadgets.
* Minimalist HTTP servers for simple usage, websocket tunnels or high 
load services.
* Users taking advantage of free hosting services with limited features 
(like Sourceforge or Geocities).
* Charities and OSS groups with better things to spend their money on 
than hosting package upgrades.
* Companies like many in the building and equipment hire industries that 
spent $500 on a website and call it expensive.

Far from being a small minority these groups and applications possibly 
make up the majority of HTML content after blogs.

> 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.
>
>   
I assume that by "pre-generated" you're referring to 
Dreamweaver/WebObjects templates rather than copy-and-paste. I find 
these irritating as quite often you are given one format but require 
another (as a FOSS user I can't/won't use Dreamweaver). Some of the best 
editors don't have any kind of template support and when they do it's 
typically native to the application. Sometimes they're even native to an 
installation (you can't export your templates). These things are bad for 
the web without some kind of accepted open specification. CSI could be 
that specification.

>> 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.
>
>   
I'm not sure where you get your statistics but these claims don't match 
my direct experience. In the typical case a web page is heavily 
dependant on included content such as CSS files, images, plugins and 
other non-embedded elements. Even geek sites like orielly.com and 
slashdot are not immune. According to websiteoptimization.com the 
orielly home page has 60 external objects. Many common sites are even 
worse. Your claim that adding HTML includes will have any noticeable 
affect on overall page loading times needs more analysis.

orielly.com:
Total HTML: 	5
Total HTML Images: 	31
Total CSS Images: 	14
Total Images: 	45
Total Scripts: 	7
Total CSS imports: 	1
Total Frames: 	0
Total Iframes: 	4


report: 
http://www.websiteoptimization.com/services/analyze/wso.php?url=http://oreilly.com/

> 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.
I like this idea, but it isn't an alternative to CSI from a designers 
perspective nor is it likely to have significant gains over current gzip 
implementations.

> 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.
>
>   
I absolutely agree that iframes aren't an alternative to CSI, not 
vice-versa.
>>> 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.
>   

You do the same thing you always have when external JS or inter-page 
requests raise the same issue. Defer JS until the DOM is in a sane state 
(onload). In my experience trying to access an object below your script 
in the source is a terrible idea and nearly always results in null 
object references that crash your page scripts.

> 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.
>
>   
As a developer I tell you this is not really a good option, and I 
disagree with your claim of "massive effort". It is a fairly 
straightforward feature as they go. Embedded SQL is a massive effort, 
WebWorkers is massive effort, client-side includes is quite trivial, 
relatively speaking. Certainly worth further investigation in light of 
its obvious benefits.

Shannon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080819/921ec715/attachment.htm>

Received on Monday, 18 August 2008 20:50:26 UTC