- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 6 Apr 2007 20:28:20 +0000 (UTC)
- To: Chris Wilson <Chris.Wilson@microsoft.com>
- Cc: Anne van Kesteren <annevk@opera.com>, "L. David Baron" <dbaron@dbaron.org>, "public-html@w3.org" <public-html@w3.org>
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