Re: Versioning and html[5]

Chris Wilson wrote:
> No one expects crashes.  On the other hand, a bunch of people did expect that
>  we didn't implement child selectors in CSS.  A bunch of people did expect 
> that we didn't understand how overflow is supposed to work.

Right.  All I'm saying is that I feel there is a middle ground between those
where a non-crash-fix may still have little enough impact that it's feasible to
make it.

>> The exact definition of what constitutes a corner case is in the eyes of 
>> the beholder, of course.
> 
> I believe you're saying the definition of what constitutes a corner case is 
> in the hands of the WG.

No.  I am saying exactly what I said, no more and no less.  You know what your
definition of a corner case is.  I don't know what that is, and I personally am
quite willing to believe you when you say that a particular change is not a
corner case for you, especially if there is data to back it up (e.g. "This
change would break 0.2% of the sites we surveyed, and that's too many for us to
be comfortable with it").

I suspect that you and the other browser vendors have pretty similar ideas of
what constitutes a corner case, though a particular change may of course break
different numbers of sites in the different browsers due to UA-sniffing on the
part of sites.  I think it's important for the browser vendors (including
Microsoft) to let this working group know when the spec changes behavior in a
non-corner case (by the definition of that vendor!), so that the spec can be
adjusted as needed, if it's possible.

It may turn out that this is impossible for some reason (e.g. if there are
contradictory non-corner cases).  I hope this will be rare, but we'll see.

All of this is getting rather far afield from the question of whether the
specification needs versioning, but since we're talking about backwards compat
anyway....

> financial burden when we (Microsoft) are sued because we broke compatibility 
> and caused some company's multi-million-dollar intranet app to break.

I agree that intranet apps are hard.  On the one hand, they are not really part
of the web (e.g. many of them don't even pretend to try to work with more than
one UA or one UA version), but it's hard for a UA to detect that something is an
intranet app.

I'm not really sure how to best handle this in general; the common claim that
web standards shouldn't worry about walled-garden content at all is not quite
satisfying to me, to be honest.

But I don't think versioning in the HTML specification will really solve that
problem...

> Pull "exploiting a security hole" out of the equation.  Crashing and 
> real-world security trump compatibility.

OK.  We have some baseline agreement.  ;)

> A single MySpace page?  Hmm, probably no big deal.

More agreement!

> A single government who locks us out of their market because we broke their
> intranet app (even if they were ua-switching and giving us bad content, and
> it was "clearly their fault")?  Probably a very big deal.

Again more agreement....  I guess this keeps coming back to the intranet
situation, huh?

> is that we have no idea how bad the real-world problem is until we ship,
> given the amount of content in intranets.

Yeah, this does put a crimp on efforts to determine the scope of changes by 
doing surveys of web content.

I guess your point is that you fundamentally have no way of judging whether 
something is a corner case?

-Boris

Received on Saturday, 14 April 2007 03:15:53 UTC