RE: Version information

On Fri, 6 Apr 2007, Chris Wilson wrote:
> > 
> >* specifications more complex.
> 
> Not for HTML5, because we are a new spec, not a delta spec.  Again, cf 
> Charter.

I'm not sure exactly what the HTML working group will be specifying, but 
one specification that I personally will be writing is one that defines 
exactly how a Web browser is to implement HTML support, in a way that, if 
implemented, will result in all the hundreds of billions of existing HTML 
documents being treated correctly.

If there's a quirks mode, that means specifying quirks mode.
If there's a flag that sets different processing modes for HTML4 and HTML5 
content, then that means specifying the processing for both.
If there's an HTML version and an XHTML version, that means defining the 
processing modes for both those too.

We need such a spec for two main reasons: first, to enable competition in 
the browser space. Right now it's impossible to enter the browser space 
without reverse engineering the browsers with the largest installed base. 
We need a document that new browser authors can refer to which will 
unambiguously and completely specify how they can enter our market.

Second, to enable people in hundreds or thousands of years to write 
browsers and view today's content, even when there are no computers 
capable of running today's browsers. If we don't do this, we are basically 
throwing away our entire heritage, making it impossible for archeologists 
of the future to learn about our culture.

>From my point of view, therefore, every single version switch increases 
the complexity of the specification I have to write. It also massively 
increases the complexity of the browsers new players have to write, and 
massively increases the complexity of the work of technoarcheologists in 
the future.

We already have 4 different versions of HTML (Quirks mode, Almost 
Standards Mode, Standards Mode, and XHTML), adding more modes is, in my 
opinion, misguided and dangerous (and, as David implied, borderline 
anti-competitive, at least if we don't specify the modes in detail).

Adding modes also increases authoring complexity, instead of decreasing 
it. Authors have widely criticised the Quirks Mode vs Standards Mode idea, 
as well as the differences between HTML and XHTML mode. Numerous sites of 
grown around trying to explain the differences and guide authors. The HTML 
vs XHTML differences in particular have been the source of heated 
discussions across hundreds of forums, blogs, and newsgroups, with people 
fundamentally misunderstanding the issues. (I'm acutely aware of these 
discussions because one of my documents is referred to frequently in these 
arguments and therefore I keep getting pointd to new ones.)


> Look, we absolutely cannot change our behavior in rendering HTML 4.01 as 
> we do today.  It is just a fantastically bad idea, for document authors 
> and users.

Then we have to specify it. That's what the WHATWG has been doing for a 
while. If we don't break compatibility with it when adding our new 
features, where's the problem?

There's an important point that may be easy to miss here: IE8 is not the 
only browser that can't afford to break compatibility with IE7. All the 
other browsers have as much motivation to be compatible with IE7 as IE8 
does. We all have to render the same content. There are areas where the 
exact processing model is not critical, because little or no content 
depends on it (e.g. it's ok to generate a true DOM tree when parsing, 
instead of generating a cyclic graph; Mozilla has proved that you can 
still render the Web with high fidelity without doing the graph). There 
are other areas where compatibility with IE7 is in fact a bad thing that 
even IE8 would want to avoid (e.g. where it crashes [1]).

But the point is, the other browsers want to be compatible with IE7 just 
like you want IE8 to be compatible with IE7, possibly more so since they 
don't have the install base clout.

Therefore *they need a spec* for what IE7 does. They also want to have to 
avoid implementing it twice, once in "HTML4-IE7" mode and once in "HTML5" 
mode, since that would double their workload.

[1] http://ln.hixie.ch/?start=1115899732&count=1


> We cannot have a continuously evolving HTML spec, that no one (document 
> author or UA implementer) can rely on not changing.  That is a recipe 
> for continuous compatibility problems.

Indeed. That's why we must absolutely ensure that HTML5 is compatible with 
all today's content, just like all browser vendors must ensure that their 
browsers are compatible with all today's content.

In fact the similie is a good one; when writing HTML5 I basically consider 
the spec to be an implementation, on par with all other implementations, 
with the same constraints. If legacy content wouldn't render correctly 
when you follow the spec, the spec is wrong.



We should not introduce versionning syntax. It would raise the barrier to 
entry in an already difficult market, it would put our Web heritage at 
risk for future generations, it would make our work as specification 
authors significantly more complicated, and it would confuse authors.

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

Received on Friday, 6 April 2007 20:28:47 UTC