Re: Separation of versioning concerns

As a reply to the subject line:
I think the two real concerns are authoring tool configuration and  
activating a given bug set in a browser. Neither is the same as the  
version number of the spec, so HTML versioning continues to be a red  
herring.

On Apr 25, 2007, at 14:45, Sam Ruby wrote:

> Observations (best if used by: April 2007):
...
> Let's acknowledge two things: (1) these people are an important  
> constituency, and (2) they are a minority.  By the second point, I  
> am not saying IE users, or even people who design pages to look  
> good in IE; instead I am talking about people who either  
> intentionally or unintentionally design pages that depend on a  
> specific version of a specific browser to look right or perform as  
> intended.
>
> My first suggestion: lets not optimize for the outliers.

I agree with everything so far.

> Let's document the hell out of this, liberally using bold font- 
> weights and uppercase text transforms, saying that those who use  
> this version *will* see changes in the rendering of this page from  
> release to release of any given browser.
...
> One possible syntax for this is the one settled on to date by the  
> WHATWG:
>
> <!DOCTYPE html>

Personally, I'd like to have exactly that, and I think side-by-side  
frozen bug modes are bad for the Web in the long run like side-by- 
side bugwards compatibility has made word processors awfully complex  
in ways that are distractions from actual document editing.

> Note that this is *totally* opt-in.

The key problem is how to convince Microsoft that the authors who  
opted into the "always fewest bugs mode" thoroughly understood the  
consequences of the opt-in was.

> Now that that is taken care of, lets turn our attention to those  
> who rightfully do care about rendering differences, not only  
> between browsers but also about rendering differences between  
> specific versions of any given browser.  This group needs a way to  
> say that this particular representation of this particular page was  
> produced specifically for IE8.0 (or whatever) and may not render as  
> intended by browsers that do not implement a rendering mode that is  
> compatible with that particular version of that particular browser.

If I've understood the Microsoft position correctly, authors who are  
in this group don't know it beforehand. And that's what this bug mode  
problem is all about.

> As such, this could be implemented as an HTTP header; perhaps with  
> a fall-back syntax employing the existing HTML <meta> tag.

Considering Ruby's Postulate, putting the mode switch inside the  
payload is safer. After all, if the switch is essential, making sure  
that the switch isn't accidentally lost is essential.

As for meta element vs. an attribute on the root element, an  
attribute on the root element would be seen as early on so that the  
mode corresponding to the switch could be in effect from the point  
when the first element is added to the DOM onwards.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 25 April 2007 12:32:53 UTC