<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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).<br>
<br>
Ian Hickson wrote:<br>
<br>
<blockquote type="cite">
<pre wrap="">* Web applications and HTML documentation on the local filesystem.
<span class="moz-txt-citetags"></span>* Autorun frontends on CDROM that are typically employed by magazine <span
class="moz-txt-citetags"></span>coverdiscs.
</pre>
<pre wrap=""><!---->
These aren't part of the use cases I am considering.
</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:Pine.LNX.4.62.0808190416040.9667@hixie.dreamhostps.com"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:Pine.LNX.4.62.0808190416040.9667@hixie.dreamhostps.com"
type="cite">
<blockquote type="cite">
<pre wrap="">I assume that by "pre-generated" you're referring to
Dreamweaver/WebObjects templates rather than copy-and-paste.</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap=""><!---->
I usually just roll my own using Perl, it's like one or two lines
depending on what you want.
</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:Pine.LNX.4.62.0808190416040.9667@hixie.dreamhostps.com"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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? <br>
<br>
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.<br>
<br>
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.<br>
<br>
Shannon
</body>
</html>