W3C home > Mailing lists > Public > public-html@w3.org > April 2007

Separation of versioning concerns

From: Sam Ruby <rubys@us.ibm.com>
Date: Wed, 25 Apr 2007 07:45:51 -0400
Message-ID: <462F3F6F.20707@us.ibm.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:15:53 GMT