W3C home > Mailing lists > Public > public-html@w3.org > October 2009

Re: ISSUE-55: Re-enable @profile in HTML5 (draft 1)

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 12 Oct 2009 01:08:40 -0700
Message-ID: <63df84f0910120108t7a96ed10ra13f691ce035edc4@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>, HTMLWG WG <public-html@w3.org>
On Mon, Oct 12, 2009 at 12:39 AM, Smylers <Smylers@stripey.com> wrote:
> Manu Sporny writes:
>> Based on the responses to the e-mails I sent yesterday, it seems as if
>> we're using slightly different definitions of "backwards
>> compatibility".
> Ah.  That's unfortunate.  Thanks for getting to the bottom of this.
> Let's use the terms 'behaviour backwards compatibility' and 'validity
> backwards compatibility' for each type.
> (But beware that when folks in the HTML5 community refer to "backwards
> compatibility" they usually mean behaviour backwards compatibility.
> 'Don't break the web' is an HTML5 motto, meaning 'Don't cause mainstream
> browsers when operating on existing webpages to behave differently for
> users than they do now'.)

>> 1. HTML5 doesn't change the behavior of anything in a
>>    backwards-incompatible way.
>> 2. HTML5 doesn't change the behavior of anything, except for parts of
>>    the HTML4 specification that don't match widely-deployed
>>    implementations.
>> I believe #1 is false, #2 is more accurate
> Using a definition of behaviour backwards compatibility, #1 is true but
> omits to mention what the baseline for comparison is; it's the behaviour
> of existing mainstream browsers.  (#1 is not true if your baseline is
> the HTML4 spec, but for HTML5 that isn't the baseline.)
> #2 is less accurate because it fails to account for all the behaviour
> which mainstream browsers have but simply aren't covered by HTML4; HTML5
> needs to be compatible with these as well the portions of HTML4 which
> are widely deployed.

Just a couple of nits that I wanted to correct here (in order to
prevent people from getting their knickers in a knot).

There's a bit too much focus on the term "mainstream browsers" above.
What we want is that content that exists today should behave as it
does today, even in future browsers that implement HTML5 and later
versions of HTML.

The only part where "mainstream browsers" come in is as a way to
measure how content behaves today. There's billions of pages out
there, and there's basically no document that describes how to process
them. What we can do is investigate how popular browsers process HTML.
In order for a browser to become popular it has to be able to process
a significant portion of the HTML pages out there. In addition, if a
browser remains popular for a while, users tend to report pages that
"don't work" to the browser maker, thus creating an effective QA tool
for how HTML processing of todays pages needs to work.

However "mainstream browsers" is but one of the tools we should use in
order to document how HTML should be processed. Other tools are
running automated searches for patterns over large number of pages,
manually examining random samples of pages, and consulting experienced
experts. All of these tools have been used.

/ Jonas
Received on Monday, 12 October 2009 08:09:36 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:00 UTC