Re: Adoption Agency Algorithm: limits lead to out-of-logical order insertions

Travis Leithead <travis.leithead@microsoft.com>, 2013-07-26 20:14 +0000:

> >From bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=20319
> 
> (Repeating on this list to get a broader set of eyes/thoughts on this topic)
> 
> Issue: this input to the parser "<b><i><a><s><tt><div></b>first</b></div></tt></s></a>second</i>" results in rendering:
> second
> first
> 
> See also: http://html5.org/tools/web-apps-tracker?from=5641&to=5642
> 
> It seems a little weird to want to "fix" this bug when all of the major
> recent browsers are 100% consistent on their parsing behavior in this
> scenario--e.g., we've successfully achieved an interoperable HTML5
> parser!

Successfully achieving interoperability by having all browsers do something
that we now know to be broken doesn't seem like what the spirit of
interoperability is meant to be.

I've raised Gecko, Blink, and WebKit bugs asking for them to update their
parser implementations to match the current spec -

  https://bugzilla.mozilla.org/show_bug.cgi?id=901319
  https://code.google.com/p/chromium/issues/detail?id=268121
  https://bugs.webkit.org/show_bug.cgi?id=119478

> What's so bad about leaving the current limits in place?

It's bad because it's something that until relatively recently we didn't
realize was causing broken behavior but now we have new information that
it's broken, and ideally we should be fixing things when we become aware
that they're broken.

> I.e., is there a site compatibility bug that is motivating this change,

There isn't, no. At least not one I'm aware of.

> or is it simply altruistic?

I don't think it'd be fair to characterize it as a black-and-white "simply
altruistic" vs binge a specific site compatibility bug.

It's not "simply altruistic". It's a fix for something that was found to be
broken in the spec but not found until after all the major browsers had
already shipped parser implementations based on the broken spec. If it had
been known before the implementations shipped it would very likely have
been fixed in the spec then and we wouldn't need to be discussing it now.

But it instead was exposed later as a result of somebody new having run
some tests that the rest of us had not thought to run yet. As you well
know, finding spec brokenness is part of the reason we have people writing
tests. They're not just writing tests to ensure interoperability of current
implementations.

> The linked bug above describes "practical limits" for the AAA which seem
> to have resulted in this problem. Yet, if this isn't really a "problem"
> for web content somewhere, then why fix it?
> 
> My inclination is to Won't Fix this bug and call this an interesting
> anomaly of the AAA (and move on). There's enough other bizarre features
> of the HTML5 parser that I'm pretty comfortable with that idea.

It may well be that other browser implementors are going to end up agreeing
with you and you'll all conclude that it's not worth changing your
implementations to fix the bug.  If that's how it turns out then I guess at
some point the spec change to fix the buggy behavior will need to be
reverted and we'll just end up deciding to have the buggy behavior becoming
a permanent part of the spec and a permanent part of the platform.

  --Mike

-- 
Michael[tm] Smith http://people.w3.org/mike

Received on Tuesday, 6 August 2013 15:43:36 UTC