Re: [svgwg] Floating point number format discordance (SVG vs CSS vs browsers)

@fsoder The fast path code you mention does detect that the value might be valid but (in the trailing wsp case) not all characters get parsed. The following actual parsing fails because of the the unparsed characters after tokenization process. W/o trailing whitespaces, even the actual parsing process passes. So there is a bug for sure. The bug can still get interpreted in two ways since the intention is not documented.

That said, the table above is still valid with bugs in WebKit and Blink, intentional or not. There are still at least 2 implementations that intentionally parse `1.e1` or `1.` as valid values in all three cases.

At least transforms and path data, as currently speced, require those numbers to be parsed as valid and there are at least 2 implementations that intentionally support this.

Adobe Illustrator won't change the behavior to the more strict parsing behavior because of potential non-web content created for printing and set-top boxes in all 3 cases but definitely not for transforms and path data. (There is no reason to change since the same numbers that are valid in Firefox are parsed to the same numbers with the relaxed syntax.) Authoring tools simply have a different audience than browsers and need to be more conservative on adding restrictions. Removing restrictions (most of the time) is easier.

If Firefox is not willing to adapt the relaxed syntax, then:
* We need to differ between a strict (CSS value mode) and quirks mode. All implementations supporting the quirks mode must parse strings that are valid in strict mode to the same values as the strict mode would but are able to parse additional content.
* Firefox accepts that it won't be fully compatible to the spec text in some minor edge cases.

IMO both solutions aren't ideal. The only other way, from the comment from @longsonr, is to support `1.e1` and `1.` for CSS numbers as well. That would certainly be a decision of the CSS WG and not the SVG WG. (Note that I do not want to mix the discussion about numbers with making SVG path data parsable with CSS Syntax. As noted above, this might not be possible anyway.) CC @tabatkins 

-- 
GitHub Notification of comment by dirkschulze
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/331#issuecomment-388211910 using your GitHub account

Received on Thursday, 10 May 2018 23:06:46 UTC