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

I'd rather an HTML version than asking authors to test in various  
browsers.

We're writing a standard, if browsers use the standard as we write  
it, then every one will display "properly." (No, this isn't always  
the case, but there's no reason we need to make content authors do  
the extra work.)

With regards to IE, we should be aware of what we do and how it might  
affect the current web, but we shouldn't just start taking IE's bugs  
and standardizing them (if I read your #1 correctly).

I suppose I like #3 the most of your options ... or perhaps #2....
Benjamin Chait: benjamin.chait@gmail.com | http://benjaminchait.net
303.641.7284 | aim - riker42 | skype - benjamin.chait

On Apr 13, 2007, at 12:10 AM, Matthew Ratzloff wrote:

>
> 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:18:32 UTC