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

No other browsers need the versioning, because they are close enough to 
existing standards, and new standards will be backwards-compatible. Hence 2.

--Dao

Matthew Ratzloff schrieb:
> 
> 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 08:48:38 UTC