[whatwg] Client-side includes proposal

[Ian Hickson]

On Tue, 19 Aug 2008, Shannon wrote:
>
> Ian Hickson wrote:
> 
> > > * Web applications and HTML documentation on the local filesystem.
> > > * Autorun frontends on CDROM that are typically employed by magazine
> > >   coverdiscs.
> >
> > These aren't part of the use cases I am considering.
> 
> I think as editor of the HTML specification you need to consider all 
> common uses of HTML - especially when you've also taken the stance that 
> there are no unsolved use cases for this proposal. Aren't you also 
> pushing for "offline applications" with your local storage proposal and 
> whatnot? I could claim this is solved by server-side databases. You 
> can't have it both ways. At any rate offline applications are certainly 
> valid uses since they represent the most common environment where SSI is 
> not even an option.

Server-based offline Web apps are applications that are served by a remote 
server and then cached locally; this is very different from non-Web cases 
such as documentation on a local filesystem or on CD-ROMs. In the case of 
non-Web content, the use of HTML is an academic point, since any format 
would work as well. The W in WHATWG stands for "Web", and that is what we 
have to focus on here.

I agree entirely that there are people using Web technologies for non-Web 
problems like content on CD-ROMs, on Intranets, and so forth, but those 
are not part of the Web and are not in our scope.


> > WYSIWYG editors are quite capable of implementing a model whereby 
> > pages are merged before being previewed, and are merged when 
> > published, removing the need for any post-publication inclusion 
> > mechanism.
> 
> Of course they can, and often they do. As I said they do it in 
> proprietary, non-transparent and non-transferable ways. CSI would be 
> open, standardised and independent of the authoring environment and this 
> is a good thing.

I agree that standardised mechanisms for author-side development can be 
useful; however, that is also outside of our scope.

I encourage you to look at XInclude, which appears to be exactly what you 
are looking for -- a standard inclusion mechanism that could be used with 
multiple independent implementations on the author side:

   http://www.w3.org/TR/xinclude/


> > > 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).
> > 
> > I usually just roll my own using Perl, it's like one or two lines 
> > depending on what you want.
> 
> Of course you do, but you are far from the typical web developer. 
> They'll use Dreamweaver templates unless a good reason exists not to.

Ok, well, then the use case is already handled.


> There is also the issue that the merge is a one-way process. If a web 
> designer absconds with the original site development files (a quite 
> common occurrence after disputes) then all you're left with on the 
> server are the merged templates which have to be unmerged again. This 
> may sound like a contrived example but I've been in this situation more 
> than once.

That's not a technical problem, it's a social problem, and engineering 
technical solutions for social problems is rarely a useful exercise.


> Merging doesn't solve the issue of content being merged with live data 
> from other sources (where keeping a page fresh requires some form of 
> cron job or CGI that may not be possible for the given service). Yes 
> iframes solve this too but then you're stuck with their limitations as 
> well.

It's true that not all services provide CGIs and cronjobs, but I don't 
think it is unreasonable to presume that people who are providing dynamic 
data of this nature can avail themselves of a hosting provider that 
supports at least SSI.


> Merging generally has the side-effect of removing the reference to the 
> include from the resulting file. This reference may have several 
> benefits such as allowing user agents to block includes from certain 
> domains and search engines to determine the authority or purpose of a 
> page segment.

It's not clear what problem these solutions are attempting to solve. I 
assure you that at least in the case of search engines, determining the 
authority or purpose of a page segment is not something that client-side 
includes would especially help us with.


> There might be other advantages such as allowing users to swap out page 
> segments for content of their choosing or other things nobody has 
> thought of yet.

CSS provides this even without CSIs.


> > Most content doesn't require blocking. Those that require blocking 
> > (like scripts) are a massive problem. Just ask any browser vendor. 
> > Safari even ends up running a second tokeniser in parallel just to try 
> > to help this. External (blocking) JS is a disaster. We don't want to 
> > be adding more features like it. We're still trying to get out of the 
> > problems blocking scripts added.
> 
> This is just a loaded way of saying the implementation problems with 
> out-of-order loading have already been solved by current vendors as best 
> they can. The blocking nature of this proposal seems largely dependent 
> on the method and quantity of scripts in the page and the amount of 
> content already in local cache. As another respondent posted this is 
> essentially an alternative to AJAX which has all the problems you 
> mentioned and more. You of all people should realise that blocking and 
> timing issues on external JS, cross-frame scripting, flash with script 
> interaction and AJAX methods aren't going away so the larger problem and 
> implementation requirements won't be solved or blocked by this proposal 
> in the slightest.

The point is that we have to learn from our mistakes and not repeat them. 
If we find that a technology is flawed (e.g. something that requires 
blocking or is non-deterministic) then we have to make sure that we don't 
introduce new technologies that are similarly flawed.


> If I have to pursue this through XSLT then I will but this just feels 
> like a HTML shortcoming to me, since as you correctly point it, there 
> are script and style considerations involved that may be specific to 
> HTML as a rendering protocol.

The seamless iframes proposal, as far as I can tell, addresses the vast 
majority of the use cases you have put forward, without having many of the 
problems of your proposal. The only thing it doesn't do as far as I can 
tell is put the DOM inside the original page in an undistinguishable 
manner, but that doesn't seem like a major problem in comparison to the 
problems we avoid (like blocking).

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