- From: Sam Ruby <rubys@us.ibm.com>
- Date: Wed, 25 Apr 2007 07:45:51 -0400
- To: public-html@w3.org
Definition: "most" ::= greater than 67% Observations (best if used by: April 2007): * most people use IE * most pages look just fine in pretty much any modern browser * most servers don't employ user agent sniffing or content negotiation * most browsers press on in face of unexpected input * versions don't need to be linearly ordered * standards compliance is a journey, not a destination This discussion has been dominated by the very real concern that there will be a vocal minority of people who invested a lot of time and effort in writing code to specifically deal with the "nuances" of dealing with the dominant browser that exists today, namely IE; and the very real fear that these people will be the ones who are disproportionately affected by any changes to that particular browser. Fair enough. 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. Let's first define a "do the best you can, otherwise gracefully degrade" version identifier, one that is unlikely to be found in any of the existing pages created by the feared vocal minority that we dare not break. 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. That being said, if the page itself is reasonably standards compliant, the expectation should be that the rendering changes will generally -- but not always -- be an improvement. To the extent that any given page is not standards compliant, and to the extent that it is possible to do so, we will establish even *less* of an expectation that changes in renderings in future versions of any given vendor's browsers will result in improvements in rendering of such pages. One possible syntax for this is the one settled on to date by the WHATWG: <!DOCTYPE html> Note that this is *totally* opt-in. The key difference from proposals discussed to date is that, from a content producers point of view, this is a set and forget option in that it does not require one to periodically revisit their pages to affirmatively state that this page now conforms to HTML version 5.7 or version 17.3 or whatever the future might hold. Needless to say, for this to work, the evolution of HTML must be incremental and done with a careful eye towards backwards compatibility, two things that seem to be a given here anyway: in particular everybody seems to be working under the assumption that serving HTML5 to a user agent that only understands HTML4 will pretty much "just work". 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. This conceptually is similar to the HTTP Accept header, but in reverse: as it is now the server that is providing a hint to the client as to what rendering it expects, instead of the client providing to the server a hint of what representation it desires. As such, this could be implemented as an HTTP header; perhaps with a fall-back syntax employing the existing HTML <meta> tag. The specific values that such a header and/or tag would have would not be specified by this working group, as such values would necessarily be vendor specific. That being said, perhaps this group could come up with the moral equivalent of the "Mozilla/4.0 (compatible)" string that seems to be ubiquitous in most user agent strings. Perhaps a full string would look something like: "HTML/5.0 (compatible; MSIE 8.0; Windows NT 5.2)" Again, whatever the syntax, note that this is totally opt-in; the key difference between this and the opt-in described above is that the opt-in is not a blank check; instead it is locked down. One requirement that this does not explicitly address is HTML fragments in places like Atom feeds. In such cases, we could either encourage "do the best you can, otherwise gracefully degrade" HTML 5.0 standards compliant mode, or come up with an idiomatic placement of the meta tag (or alternatively, define an attribute) within the content itself. Other than that, does this address all the other constituencies, adequately protect the existing web, and yet still manage to provide the necessary flexibility to browser vendors to address their user's requirements? - Sam Ruby
Received on Wednesday, 25 April 2007 11:46:01 UTC