Revamp coords parsing to be more compatible and less insane

[zcorpan]

The old parser tried to mimic IE as close as possible. Now Edge is instead interested in aligning with Gecko/WebKit. This new algorithm was designed by studying implementations as well as invalid Web content.

At the same time, support parsing of floating point numbers, as suggested by @travisleithead in the bug below.

Fixes https://www.w3.org/Bugs/Public/show_bug.cgi?id=28148.

[annevk]

Do we have tests for how many browsers this new algorithm matches?

[zcorpan]

I don't know how to test this in an automated fashion :( since the parsed list is not exposed and the only way to tell what happens, AFAIK, is with hit testing or looking at focus rings.

[zcorpan]

But as noted in the bug, the new algorithm doesn't exactly match any one browser, but is more of a mix of the different approaches that seems to give good results for actual Web content.

[zcorpan]

It could be tested using elementFromPoint although this Gecko bug prevents it from working in Gecko.

[zcorpan]

@bzbarsky @jchaffraix @hober is there interest in aligning coords parsing? I'd be happy to write some tests in web-platform-tests.

[fsoder]

If there's sufficient interest for this from other parties, I can work on aligning the parser in Blink.

[Ms2ger]

I'm definitely interested in having tests by the time we implement image maps in Servo :)

[bzbarsky]

I'm interested in aligning parsing here at least in theory. This is not code that's well-owned in Gecko and hasn't been changed much in a long time; I don't feel like I have a good understanding of what's likely to be compatible here and what's not. But if there's a simple enough and compatible spec I would certainly support it getting implemented.

[zcorpan]

Bugs filed:
https://connect.microsoft.com/IE/feedbackdetail/view/2245506/implement-area-coords-parsing-per-spec
https://bugzilla.mozilla.org/show_bug.cgi?id=1240011
https://bugs.webkit.org/show_bug.cgi?id=153124
https://code.google.com/p/chromium/issues/detail?id=578114

[annevk]

I would be okay with merging this given that the old algorithm aligned with IE and nobody wants to implement that anymore, and given that we now have tests and bugs filed.

[zcorpan]

Tests are reviewed now and @fsoder has an implementation that passes the tests. Can we merge, or does someone else want to review also?

[domenic]

"or" before U+003B

[domenic]

A couple minor editorial nits. LGTM once fixed. Very nice to just reuse the float algorithm instead of the existing complicated thing.

[zcorpan]

@@ -4557,13 +4557,13 @@ a.setAttribute('href', 'http://example.com/'); // change the content attribute d
      U+002E FULL STOP, or U+002D HYPHEN-MINUS characters. This skips past leading garbage.</p></li>

      <li><p><span>Collect a sequence of characters</span> that are not <span data-x="space
-     character">space characters</span>, U+002C COMMA, U+003B SEMICOLON characters, and let
+     character">space characters</span>, U+002C COMMA, or U+003B SEMICOLON characters, and let
      <var>unparsed number</var> be the result.</p></li>

-     <li><p>Let <var>number</var> be the result of using the <span>rules for parsing floating-point
-     number values</span> for <var>unparsed number</var>.</p></li>
+     <li><p>Let <var>number</var> be the result of parsing <var>unparsed number</var> using the
+     <span>rules for parsing floating-point number values</span>.</p></li>

-     <li><p>If <var>number</var> is an error, let <var>number</var> be zero.</p></li>
+     <li><p>If <var>number</var> is an error, set <var>number</var> to zero.</p></li>

      <li><p>Append <var>number</var> to <var>numbers</var>.</p></li>

[zcorpan]

Thanks for the review!

[zcorpan]

FYI, the relevant fixes have now landed in Blink. @fsoder++