Re: Separation of versioning concerns

+1 to all you said!

And if people fear that <!DOCTYPE html> is too easy to copy/paste
without knowing what it means, let's try to find something similar to:
<!DOCTYPE html -- by copy/pasting this line, I aknowledge to be using
an always evolving HTML dialect-->

2007/4/25, Sam Ruby:
>
> 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
>
>


-- 
Thomas Broyer

Received on Wednesday, 25 April 2007 13:50:08 UTC