Re: Opt-in solutions ...and problems (was Re: Versioning and html[5])

On Fri, 13 Apr 2007 06:10:07 +0200, Matthew Ratzloff  
<matt@builtfromsource.com> 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.

This is IMHO what we should aim for.

>     + One specification governs all behavior; easy for authors

Not only for authors, but also for UA developers, and new UA vendors  
trying to enter the market.

>     - IE bugs are introduced into the specification

Why is this a problem? If all UAs agree on the same set of bugs, we have  
achieved interoperability, which is our aim here.

>     - Deprecating, removing, or otherwise specifying a change in usage  
> is severely limited

No, it would not limit what we can deprecate, remove, or otherwise specify  
a change in usage at all. What authors have to do is completely orthogonal  
to what UAs have to do. e.g. we can forbid authors to use <plaintext> but  
still require all UAs to parse it in the same way.


> 2. Make no allowances for browsers that do not comply with the standard  
> as specified.  Require that these browsers implement their own opt-in  
> mechanisms (a la IE's conditional comments).
>
>     + Specification does not inherit UA-specific bugs

This is not a pro, since it would mean that we would never achieve  
interoperability between UAs on today's content. New vendors trying to  
enter the market would thus still have to reverse engineer another UA,  
which is what we're trying to eliminate here. In 500 years from now, it  
might not even be possible to reverse engineer today's browsers, and so it  
would be impossible to write a new browser from scratch, which means that  
today's content consisting of hundreds of billions of pages will go away  
into a black hole.

>     - Could ultimately result in Microsoft not implementing or only  
> partially implementing specification when spec differs significantly and  
> no clear way to opt in

Indeed.


> 3. Allow authors to peg pages to an HTML version. This might take the  
> form of a DOCTYPE switch, an <html version="5.0"> attribute, or some  
> other means.
>
>     + Content will always render the same as it does today

Same comment as your (2) pro above.

>     + Elements can be changed and deprecated as deemed necessary

Same comment as your second (1) con above.

>     - If a rendering bug becomes prevalent and is subsequently fixed, is  
> the specification updated to account for this?  HTML 5.1?  HTML 5.2?

I don't understand what you mean here. If we want to achieve  
interoperability on today's content, we have to specify the bugs today's  
content relies on (including quirks mode, IMHO).

>     - Introduces significant barriers to new browser development, since  
> browser makers must version their rendering engine

Indeed. This is a major problem, IMHO (it already is a problem today --  
let's not make it even worse by introducing even more rendering modes).

>     - What happens if a page specified for HTML 5 is later updated (as,  
> for example, by a different author) only to use a new element from HTML  
> 6, but has content dependent on HTML 5 rendering?

In my world it would Just Work, just like if the content depended on  
quirks mode rendering. (<canvas>, an HTML5 feature, works fine today under  
an HTML 3.2 doctype in today's browsers.)

>     - IE conditional comments are still needed for compatibility with  
> older versions

Until MS have completely and correctly implemented HTML5 (without  
versioning), they will need CCs. When they have, they might be able to  
safely drop them. CCs are powerful enough for authors to work around bugs  
in existing IEs, and they can do so without making assumptions about which  
bugs next IE will have.


> 4. Allow authors to peg pages to the latest browser versions that the  
> page has been tested in and guaranteed to work with.  This might take  
> the form of:
>
>     <meta name="User-Agent" value="Internet Explorer 7.0" />
>     <meta name="User-Agent" value="Firefox 2.0" />
>     <meta name="User-Agent" value="Safari 2.0" />
>     <meta name="User-Agent" value="Opera 9.2" />
>
> In this case, it would obviously be better to peg it to rendering  
> engines and not browsers themselves, but that's probably asking too  
> much.  AOL, Camino, Netscape, Konqueror, et al would just have to check  
> for the most common strings that match their rendering engine.
>
>     + Content will always render the same as it does today

Same comment as your (2) pro above.

>     + Elements can be changed and deprecated as deemed necessary

Same comment as your second (1) con above.

>     - Introduces significant barriers to new browser development, since  
> browser makers must version their rendering engine

Same comment as your second (3) con above.

>     - What happens if a page specified for Internet Explorer 7 is later  
> updated only to use a new element defined in IE 8, but has content  
> dependent on IE 7 rendering?

Same comment as your first (4) con above.

>     - IE conditional comments are still needed for compatibility with  
> older versions

Same comment as your third (3) con above.

-- 
Simon Pieters

Received on Friday, 13 April 2007 10:45:40 UTC