[Bug 28148] Improve parsing of numbers for coords attribute

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

Simon Pieters <simonp@opera.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |travil@microsoft.com
              Flags|                            |needinfo?(travil@microsoft.
                   |                            |com)

--- Comment #4 from Simon Pieters <simonp@opera.com> ---
(In reply to Travis Leithead [MSFT] from comment #3)
> Only IE has this behavior (and is thus compliant with the wording in the
> spec), test page: http://jsfiddle.net/6mr5s457/
> 
> Chrome/FF’s behavior is noncompliant on two accounts.  One, they don’t
> implement the algorithm as specified or they’d have the same behavior as IE.
> Two, they are accepting floating point values even though the spec says to
> use integer parsing.
> 
> Even assuming we change the spec to allow coords to accept floating point
> values (which we should), it’s strange that Chrome/FF don’t do any
> normalization in this parsing – e.g. ".100" stays as such, and isn’t
> normalized to ".1" or "0.1".

Normalized where? The parsed value is not serialized anywhere per spec. .coords
just reflects as a plain DOMString, i.e. same as getAttribute.

> So I recommend a few things:
> 1. Fix the integer list parsing algorithm so it doesn’t just drop leading
> decimals (instead these should become 0, for both positive and negative, in
> order to match the truncating behavior that other floating point numbers get
> in this algorithm):
> http://www.w3.org/TR/html5/infrastructure.html#rules-for-parsing-a-list-of-
> integers

OK.

> 2. Rephrase coords to allow a valid list of floating point numbers.  I don’t
> think there’s an existing algorithm for this (there’s an algorithm for
> floating point numbers, and a list of integers, but not a list of floating
> point numbers):
> http://www.w3.org/TR/html5/embedded-content-0.html#attr-area-coords

Should parsing of this list try to be compatible with IE's coords parsing
(modulo the necessary differences to support floats), or Gecko/Blink? (I guess
we could re-check the web compat situation.)

> 3. I didn’t look very hard at the floating point number parsing algorithm,
> but if it doesn’t specify normalization (e.g. trim trailing 0’s and enforce
> a digit before the decimal) that might be worthwhile to discuss.
> http://www.w3.org/TR/html5/infrastructure.html#rules-for-parsing-floating-
> point-number-values

Again normalization implies serialization...

> 4. There’s a lot of ambiguity around coords whether the requirements are for
> the UA or the author.  Would be good to clarify so these are actually
> testable.
> http://www.w3.org/TR/html5/embedded-content-0.html#attr-area-shape-circle

I don't see what's ambiguous? See
https://html.spec.whatwg.org/multipage/infrastructure.html#conformance-classes

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 30 March 2015 20:37:09 UTC