- From: Dannii <curiousdannii@gmail.com>
- Date: Wed, 25 Apr 2007 21:57:06 +1000
- To: "Sam Ruby" <rubys@us.ibm.com>
- Cc: public-html@w3.org
- Message-ID: <af3e73120704250457l278ef22ey907ddb2ca5b44602@mail.gmail.com>
Great post. On 4/25/07, Sam Ruby <rubys@us.ibm.com> wrote: > > > 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:57:21 UTC