Re: Separation of versioning concerns

Great post.

On 4/25/07, Sam Ruby <> 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