Re: The argument for |bugmode|

Terje Bless wrote:
> mattraymond@earthlink.net (Matthew Raymond) wrote:
>> b) The version number increases bandwidth.
> 
> Lets just dispense with this one right off the bat. In one 
> proposed syntax this boils down to one single byte.

   No, because we've already discussed how using "html5" instead of
"html" throws legacy browsers into quirks mode. Why would I want quirks
mode rendering in a legacy browser for compliant HTML5 content?
Furthermore, for XHTML, the current WHATWG specs gets rid of the doctype
entirely. Therefore, authors of XHTML5 would have to reintroduce the
entire <DOCTYPE> element to support the version number.

> You'll waste 
> more bandwidth on a GIF that's not perfectly optimized; that 
> single byte--no matter how insanely many page views you want 
> to postulate--will be literally impossible to detect.

   Even if you were right (which I just indicated isn't the case), we'd
still need a mechanism that addresses the bug compatibility of a
specific version of a vendor's user agent, not a specific version of
HTML. Therefore, we'd have to tack something on later that would include
that information, and that would take more than one byte.

   Count the bytes here:

| bugmode="IE7"

   I count 14. Is that a huge amount of bandwidth. And if you want
standards-compliant rendering, you leave it off entirely, and the count
drops to zero.

> For alternate equivalent syntaxes, a one byte difference may 
> possibly be a valid consideration, but in the general case 
> bandwidth is not a valid argument one way or the other.

   It is for a company that gets massive numbers of hits like Google or
Yahoo.

> mattraymond@earthlink.net (Matthew Raymond) wrote:
> 
>> Terje Bless wrote:
>>> If the standard says «This is how you identify a given document as
>>> HTML5 if you are a conforming HTML5 UA.» then there will be no need for
>>> one UA to encourage its users to say «If you are the UA from Vendor
>>> Foo, but no other UA, I want you to use this particular, proprietary,
>>> optional behavior.»
>>
>> False. [...]
> 
> You dispute that having the standard specify a way to achieve 
> "Goal X" will obviate the need for "Vendor Y" to invent 
> its own way to achieve that goal?

   I don't dispute "a way". I dispute the use of HTML versioning to
achieve "Goal X".

>>> You may not have need of a way to unambiguously identify the author's
>>> intent to utilize HTML5, but one member of the WG has expressed a need
>>> for this functionality and it behooves us to listen very carefully and
>>> attempt to accommodate this need.
>> Tying bugs to a version number doesn't make them go away,
> 
> I suggest you contact the IE team and make that argument to them.

   Dude, the head of that team is the working group chair. If he's not
going to listen, what's the point? I'd be trying to get a browser
development team to mutiny against their boss!

>> Lets reference the Proposed Design Principles: "Solve Real Problems",
>> Versioning doesn't solve any real problem, because new version
>> numbers don't make user agents compliant, and because it encourages the
>> proliferation of new modes in user agents that increase code complexity.
> 
> One of the participants of this working group has pointed out a 
> real problem that they have, that they need to solve, and which 
> they would very much like this standard to accommodate. That's a 
> Real Problem that needs Solving.

   No, the real problem is two-fold.

   The first problem is that bugs become exponentially more expensive
the later you catch them. Microsoft, rather than catching the bugs early
and releasing standards-related fixes often to minimize the damage,
wants a switch to route around the damage.

   The second problem is that the guy in charge of browser development
at Microsoft has rejected a perfectly reasonable solution without giving
sufficient justification. I've seen him discuss how a proprietary switch
based on version of Internet Explorer might work, so I'm not even sure
HTML versioning will prevent Microsoft-proprietary switches anyways.

> You seem to be arguing against solving it for reasons of 
> theoretical purity and your speculations as to what idealized
> world might possibly have come to pass if this problem didn't 
> exist in the first place.

   Versioning, the solution proposed, solves theoretical problems. If
HTML6 ends up being a true superset of HTML5, what problem does
versioning solve? The whole argument is that problems MIGHT arise,
therefore we should add a version number JUST IN CASE. However, the
burden of adding a version number into markup are real, and problems
like remembering whether feature X was introduced in HTML5 or HTML6 lurk
on the horizon.

>>>> "Priority of Constituencies",
>>> Although Microsoft has considerable marketshare, they are the only
>>> browser vendor I know of that is currently asking for this.
> 
> And because they're Microsoft we shouldn't listen to them?

   We've listened extensively. Unfortunately, Microsoft hasn't really
provided a valid argument for the defense of their position. Listening
and acquiescing are not the same thing.

> They have a real problem that they need to solve, and would 
> prefer to solve within the confines of this standard. This 
> problem is also one that comes directly from the _users_ of this 
> particular UA.

   You're blaming the users for doing what they had to do to get things
to render correctly in IE?

>>>> and "Well-Defined Behavior"
>>> What's defined? All you've done is stick a number in the markup that
>>> can be used by the user agent in an UNDEFINED manner.
> 
> If the standard defines the particular syntactic construct then 
> it will be openly specified and peer reviewed.

   A specific syntactic construct for WHAT??? That's what's not defined.
The non-conformant behavior we're talking about could be anything, and
the versioning markup doesn't identify that to someone reading the page
in any way.

> If not they will 
> be forced to implement a proprietary way to do it, with no peer review.

   No one is forcing them. In fact, we've pretty much bent over
backwards to come up with a spec-blessed solution for them. Chris Wilson
is rejected our proposals, insisting on versioning to solve the problem.
(And as Dao informs us, they're also using a proprietary browser-centric
switch as well.)

>> 1) There is real harm:
>>
>>    a) Switching on the version encourages Microsoft to leave bugs
>>       unfixed for a specific version.
>>
>>    b) The version number increases bandwidth.
>>
>>    c) Different modes for each version increases code complexity.
> 
> "Encouragement" one way or the other is not an argument I 
> consider valid in this context.

   Why would we want a spec to promote poor software design and
increased user agent complexity? Seems like a valid argument to me.

> Neither is [bandwidth].

   Care to actually back that argument up? Just because some web author
can't optimize a GIF doesn't mean that bandwidth isn't important.

> Code complexity of implementations is in general a good 
> argument, but in this case the burden is on the implementors who 
> actually wish to make use of such behavior.

   If a significant number of pages are written to use a specific bug
compatibility mode, vendors will have to implement that mode to stay
competitive, and considering IE's marketshare, that would probably end
up being the case. Therefore, your argument that implementors don't have
to support those modes is laughable.

> As you so vehemently 
> point out, only one vendor has expressed a need for this as yet, 
> so no other implementor of the specification will be burdened 
> with this additional complexity. As for Microsoft, they've 
> stated they need to implement this no matter what the standard 
> does or does not provide for, so there is actually no added 
> complexity for them either.

   They're a big enough player that providing a solution that's the
least painful and least problematic is to our benefit. However, if they
insist on alternative solutions that are harmful to the standards
community, there's no reason to condone that.

>>> 2) My |bugmode| attribute works just fine for selecting the proper mode,
>>> and can even be use preemptively so long as the UA identifier is known.
> 
> I'm sorry. Did you somehow get the impression that I was arguing 
> in favor or against one specific syntactic construct to hang 
> this requirement on?

   Read the subject line.

> I have some thoughts on how the standard might implement this 
> requirement, but I haven't as yet written of it. If I've given 
> that impression--perhaps you thought I was arguing against 
> your specific syntax?--then I apologize; that was not my intention.

   At the beginning of your last message, you specifically defended
versioning. "One byte". Remember?

>>> 3) If Microsoft intends to make releases of IE more frequently that the
>>> W3C releases HTML versions, then they're going to need a switch unrelated
>>> to the version anyways.
> 
> Perhaps. I believe Chris said he'd be happy with just including 
> the version in the document type name, so apparently they feel 
> this would be sufficient.

   What happens when they change their minds? What happens when a
different vendor says then need a mode switch? Why should we spec a poor
solution just because Microsoft is okay with it?

Received on Saturday, 21 April 2007 20:18:11 UTC