W3C home > Mailing lists > Public > public-html@w3.org > April 2007

Re: A Compromise to the Versioning Debate

From: liorean <liorean@gmail.com>
Date: Mon, 16 Apr 2007 22:12:48 +0200
Message-ID: <cee13aa30704161312g3a6b8faaj418ff57540cc908a@mail.gmail.com>
To: "HTML WG" <public-html@w3.org>

Not going to answer to any particular message here, since I've just
read about ten days of mails to this list, just voicing my opinion on
the mode switch and versioning issues.



1. I understand Microsoft absolutely require a "no seriously I do NOT
rely on your bugs and proprietary behaviour" switch from current
standards mode to something better. I don't think HTML5 can go without
one (though it doesn't have to be explicitly there for this purpose in
the spec) because this switch is absolutely needed to not break
current standards mode content in IE.next.

The problem is that content relies on BOTH standards behaviour in some
browsers and non-standard in others. Implementations (including specs)
can't change to the other behaviour without breaking the content that
is written to their current behaviour. And content uses many various
bugs and features to decide what to do. There's user-agent string,
browser proprietary objects and behaviours such as conditional
compilation or conditional comments, browser bugs in HTML, DOM, CSS,
heck even detecting the order of fields in an HTTP request  - you name
it - that is used to trigger particular behaviour when it comes to
many areas such as browser objects (proprietary or not), DOM, CSS etc.
These are also things you can't change the spec to fix, because then
you'd break content written for the already compliant browsers.

For IE.next to avoid breaking current content while fixing incorrect
implementation I don't see any way to avoid an opt-in.



2. The DOCTYPE declaration is already used for switching. Developers
are already used to it. If you need a mode switch in the HTML source,
I think it would be best for everyone if we reuse this one instead of
adding a new one.



3. I strongly believe web developers need this switch to say "no
please, give me the best you have", not "please give me behaviour
matching the bugs of version X". Why? For several reasons:

One, because the bugs lie in many areas. Rendering mode switching for
CSS float behaviour is one example that is mostly independent of HTML.
But some examples are tied more closely to the HTML parser and the
HTML DOM:
- Whitespace nodes in the DOM or not.
- The construction of a DOM tree where a straight child/sibling/parent
traversal method goes into a cycle.
- Whether attributes are in the attributes collection when unspecified or not.
- Whether names are included when using getElementsById.
- etc.
There are also some bugs that really have nothing at all to do with
HTML that should be fixed in this mode, such as ECMAScript compliancy:
- There are numbers that are pathological in JScript when using the
current implementation of toFixed that work perfectly in all other
browsers.
- Array.prototype.split and handling of captured submatches.
- Trailing commas in array literals add to the length.
- etc.

Essentially, for it to make sense to have versioned switch in HTML
that govern not only HTML parsing but also DOM, ECMAScript, CSS, HTTP,
URI handling etc. you'd have to synch the spec releases or brings them
together in one place, and also add cross spec testsuites and
interoperability requirements.


Two, because it doesn't make sense to bind one spec (and all
tangential specs that are also affected by this mode) to a single
implementation when the implementation isn't the actual reference
implementation of the spec.


Three, there likely will be several versions of IE that supports
HTML5, and HTML5 content should not be limited to a mode decided by
the first version that supports it.



4. "Make it easy to do right and hard to do wrong" - make an official
method of opting in to incorrect implementation behaviour instead of
making authors rely on filters such as working around buggy behaviour
using other bugs, hacks or proprietary feature detection. For example
with CSS, an opt-in to buggy behaviour could take the form of a custom
vendor prefix such as -ie{version}- for properties and values and for
whole rulesets you could have an @-ie{version}- at-rule for opting in
to the behaviour of that version. For DOM similar prefixes could be
used. For ECMAScript a conditional compilation switch could be used.
For HTML, conditional comments.

In other words, make the standards mode be the latest but make it easy
for authors to specify that they want an older behaviour. Without
hacks.
-- 
David "liorean" Andersson
Received on Monday, 16 April 2007 20:12:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:15:53 GMT