- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 25 Apr 2007 15:32:39 +0300
- To: Sam Ruby <rubys@us.ibm.com>
- Cc: public-html@w3.org
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