Why interoperability (was Re: design team notes)

On Fri, Apr 22, 2011 at 2:42 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 22.04.2011 20:14, Maciej Stachowiak wrote:
>> For purposes of HTML5 and other client-side Web standards, and also from
>> the perspective of most browser implementors, the problem to solve is:
>>
>>     Define URL processing for URLs found in Web content, with the
>> following constraints:
>>     - Compatible with existing Web content.
>>     - Once implemented, interoperable among all browsers and other
>> programs that want to do browser-compatible processing of Web content.
>>     - Defines behavior in all cases, including errors.
>
> i) would it be sufficient to define preprocessing and then delegate to
> existing specs?

That's one approach that could work.  Ultimately, we'll need to do
that at some level.  For example, we'll certainly defer to UTF-8 at
some point in the document.  It's more a question of how low down in
the stack do we need to go in order to precisely and correctly specify
the behavior we wish implementations to have.

> ii) how do measure "interoperable" and "compatible"? For instance, if Webkit
> does A and IE does B, and B conforms to the specs, what does that mean?

It likely means that further study and judgement is required.
Interoperability is easy to measure.  Compatibility is often more
expensive, so we use experience and judgement to guide us.  As an
example, the data Boris provided in
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=12543> is quite useful
w.r.t. compatibility.

> iii) even if all browsers "interoperate", but other widely deployed other
> consumers do not (such as URI parsing libs), what does that mean?

It's entirely likely that browser vendors wish their implementations
to interoperate more precisely than other implementors.  Precise
interoperability is expensive and painstaking, which means folks need
to be motivated in order to achieve it.

>> Compatibility with RFC3987 is a nice-to-have, but these requirements take
>> strict priority.
>>
>> I recognize that not everyone may be interested in solving this problem.
>> That is ok, but please do not try to stop those who do wish to solve it.
>
> I'm trying to understand the nature of the problem first. I have some idea
> about some aspects (whitespace handling, I18N in query parms, \ vs /, ...).
> I'm not sure this is a complete list, though.

We've discussed before why browser vendors are motivated to achieve as
much interoperability as they can.  Here's a brief summary:

Folks who develop web sites have a history of not testing every aspect
of their web site in every browser.  This is especially true in
markets where not every browser is broadly represented.  For example,
the Asian market has historically skewed towards IE, and, currently,
mobile is skewed quite heavily towards WebKit.

Suppose IE and WebKit fail to interoperate on some aspect, say URL
parsing.  Further suppose Asian web sites come to depend on IE's
behavior and mobile sites come to depend on WebKit's behavior.  Now,
both IE and WebKit are in a tough positions.  Niether can access the
other's market because they'll break web sites in their "home"
markets.

We've seen this story play out in many, many situations over a long
period of time.  In areas of strong interoperability, there's less
risk of being locked into supporting vendor-specific behavior and less
risk of fragmenting the web into pockets of incompatibility.  In areas
of weak interoperability (e.g., because low-quality specifications
force browser vendors to reverse engineer each other), there's a trail
of compatibility tears.

In addition to these selfish motivations, some browser vendors (e.g.,
Mozilla, Google, and others) explicitly have as part of their mission
to encourage competition in the browser market.  One way to do that is
to reduce the barriers to entry into the market, which means
high-quality specifications that reflect reality and contain
sufficient detail that a new entrant in the market can implement the
spec and actually interoperate with the long tail of web sites
browsers need to support in order to be competitive.

Now, other folks likely have different motivations for being involved
with this work, but that's why I'm here.

Adam

Received on Saturday, 23 April 2011 06:42:06 UTC