Re: Opt-in solutions ...and problems

At 11:11 +0100 UTC, on 2007-04-13, Bruce Boughton wrote:

> Matthew Ratzloff wrote:
>>
>> 1. Provide no opt-in switch, but do not write the specification in
>> such a way that breaks content in Internet Explorer.  This, in effect,
>> means adding to the spec the IE-specific bugs that at least 1% of
>> websites coded with IE in mind rely upon.
>>
>>    + One specification governs all behavior; easy for authors
>>    - IE bugs are introduced into the specification

I wouldn't rate this as a minus. This would be 'no more' than making reality
official.[*] All UAs already need to copy (not all but many of) IE's bugs
today. In fact, they currently do this by *silently guessing* what the author
meant -- one of the windmills I like to fight ;) -- meaning users currently
simply cannot trust that what they see is what the author meant. (The fact
that most users are unawaree of this doesn't change that.) Web Apps 1.0's
(WHATWg's 'HTML5') approach of standardising IE's bugs removes the guess
factor from that equation. (Provided this aim can and willl actually be
achived, that is.) See
<http://www.whatwg.org/specs/web-apps/current-work/multipage/section-parsing.html#parsing>.
(Ian Hickson explained this better to me on the WHATWG mailing list, back in
December 2006, in several messages in the thread "several messages about XML
syntax and HTML5". The list archive's search meachnism at
<http://lists.whatwg.org/pipermail/whatwg-whatwg.org/> is too limited to find
them right now though.)

Looking at it this way, I think this aspect should rather be qualified as a
plus.

There are only two other realistic options I can imagine. One is that people
stop using IE -- which they might, but this WG won't make them. The other is
that authors stop relying on IE bugs, which is something I think that can
actively be stimulated by repairing and setting standards for authoring
tools, as the Web Repair Initiative aims for.

>>    - Deprecating, removing, or otherwise specifying a change in usage
>> is severely limited
> I do not see how deprecating something is limited by this.  The spec
> should say what authors should use (strict in what you specify) but
> browsers' support should be backwards-compatible (permissive in what you
> accept), so deprecated content should display correctly, but authors
> shouldn't use it.

Exactly.

The one problem I still do see with this approach is that it sends Microsoft
the signal that they can continue to add any bug they like in the future --
the rest of the world will copy it after a few years and in the mean time
Microsoft keeps its advantage. The easiest way to do that is to provide
authoring tools that spit out broken web pages that 'happen' to work in IE.
That's why I invited Chris/Microsoft to (in some form or other) participate
in the Web Repair Initiative. It might give more credibiliy to the statement
that old, broken web pages will just "rot away", and might help remove some
doubts that people probably have about Microsoft's willingness to make
'HTML5' worth the trouble.

(Btw, I have no doubt that other companies woudl act the same, when in the
same position. The problem is with the mechanisms, not with a specific
company with a specific name.)


[*] Just like W3C did with HTML 3.2 and CSS 2.1.


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Sunday, 15 April 2007 04:44:04 UTC