[whatwg] Client-side includes proposal

Ian, I have some final clarifications to make then if you wont change 
your mind I'll leave this one alone or pursue it elsewhere. You've 
previously made it abundantly clear that nothing happens around here 
with your approval (the formal definition of editor I suppose).

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.

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

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.

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. 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. Merging is basically a lossy conversion in so 
many ways.

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

Even when content doesn't block the results are far from ideal. Issues 
such as 'flash of unstyled content', excessive repainting and content 
jumping around all over the place are all artifacts of the real issue - 
which is (X)HTML is an imperfect streaming format. As a designer of 
primarily dynamic sites I rarely have the luxury of setting explicit box 
sizes so the blocking/reshuffling issue is something I've learn't to 
live with. I generally run scripts onload or at least using 'defer' so 
blocking is mostly a non-issue. As I said earlier if the browser decides 
not to paint my banner till the end then I really don't care; and if the 
content rendering is somehow blocked by the wait for banner code then 
I'd consider reordering my includes or cleaning up cross-include scripts 
until it doesn't.

You just don't have the statistics and research to define blocking 
delays in real user experience terms. To be honest your justification 
while technically accurate seems fudged in respect to actual impact. I 
don't believe the problem is anywhere near as serious as you make it out 
to be. In a perfect world maybe every web page would be a single 
request, with everything loaded and rendered in the order we need it; 
but then that's basically Flash isn't it?

At the very least the choice to use CSI and the impact of its 
side-effects is something a designer has a lot of control over. A lot 
more control than SSI, proprietary templates and source preprocessors 
with a lot less complexity (for the designer). All of these alternatives 
have their own issues - often they are showstoppers. CSI solves a 
specific class of problem that is so common practically every 
programming language and template system provides it in one way or 
another. HTML, even with it's focus on hyperlinking content from 
disparate sources, is the odd one out.

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. I've offered many good arguments for this 
proposal. The rest depends on those arguments being weighed across your 
claims of alternatives and implementation problems. You should have a 
pretty good idea how I view those arguments by now.

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

Received on Tuesday, 19 August 2008 00:42:38 UTC