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
