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

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

From: Matthew Ratzloff <matt@builtfromsource.com>
Date: Thu, 12 Apr 2007 21:10:07 -0700
Message-ID: <013601c77d81$9f258d40$0501a8c0@notebook>
To: <public-html@w3.org>

Everyone,

There's currently a lot of back and forth on the list but very little 
concrete has been laid out.

As I see it, these are four possible solutions to this problem of "opt-in" 
rendering.  I've added a few pros and cons--I'm sure others have more in 
mind.

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
    - Deprecating, removing, or otherwise specifying a change in usage is 
severely limited

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
    - Could ultimately result in Microsoft not implementing or only 
partially implementing specification when spec differs significantly and no 
clear way to opt in

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
    + Elements can be changed and deprecated as deemed necessary
    - If a rendering bug becomes prevalent and is subsequently fixed, is the 
specification updated to account for this?  HTML 5.1?  HTML 5.2?
    - Introduces significant barriers to new browser development, since 
browser makers must version their rendering engine
    - 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?
    - IE conditional comments are still needed for compatibility with older 
versions

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
    + Elements can be changed and deprecated as deemed necessary
    - Introduces significant barriers to new browser development, since 
browser makers must version their rendering engine
    - 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?
    - IE conditional comments are still needed for compatibility with older 
versions

Thoughts?

-Matt

On Apr 12, 2007, at 22:46, James Graham wrote:
> the only solution I can see is to force authors to specify their  opt-in 
> to the bugs and features of a particular UA  using e.g.  <meta 
> name="ua-version" value="IE7"> to specify IE7+ should work in  IE7 mode 
> when rendering the document. 
Received on Friday, 13 April 2007 04:09:44 GMT

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