Chrome does not implement all SVG floating point number formats
Reported by
tshin...@gmail.com,
Jul 14 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Example URL: https://codepen.io/tshinnic/full/XgOvVP/ Steps to reproduce the problem: 1. Any SVG <path> that uses floating point number format "nnn." 2. 3. What is the expected behavior? Using a number format documented in the SVG specification should not cause <path> drawings to be discarded. What went wrong? Path strings using number formats "nnn", "nn.nn", or ".nnn" were displayed, but any string employing number format "nnn." is rejected without display. All number formats in the SVG specification should be accepted and understood. Among the example tests at https://codepen.io/tshinnic/full/XgOvVP/ are: <path d="M 30 75 L 70 75" stroke-width="5" stroke="red" fill="none" /> <path d="M 30 75 L 70 75. " stroke-width="5" stroke="black" fill="none" /> If the format "nnn." is supported then a black line will hide the red line. (This is in the style of the Web Platform Tests) Only the red line is displayed unfortunately.. As mentioned in the note at https://github.com/w3c/svgwg/issues/331 , FireFox and Chrome appear to have implemented only the number formats described by CSS. SVG has always had a fourth format beyond the CSS spec. The more recent implementation of SVG in Edge (and after all the harassment they got for not following standards) *does* implement all the SVG number formats. Please read that note at https://github.com/w3c/svgwg/issues/331 and additionally review the test demo at https://codepen.io/tshinnic/full/XgOvVP/ This is embarrassing all around. The 'nicest' resolution would be for FireFox and Chrome to say 'oops' and implement the rest of the SVG spec. That there were no tests and everyone (?) has worked-around the unimplemented spec may drive a vendor push to drop the number format from the SVG spec. Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? No Does this work in other browsers? No FireFox (Edge works correctly) Chrome version: 59.0.3071.115 Channel: stable OS Version: 10.0 Flash Version: A fiat decision would be very unfortunate without at least some discussion at the SVGWG issue noted above.
,
Jul 14 2017
The behavior of Blink (inherited from WebKit) appears to stem from https://bugs.webkit.org/show_bug.cgi?id=15468 (which isn't providing much in terms of motivation...) FWIW, Presto Opera (Opera <= 12) also recognized 'digits "."' as a valid number.
,
Jul 14 2017
I would support fixing it for compatibility, but then we are already compatible with Mozilla so I think a spec discussion should come first. fs@, could you drive that?
,
Jul 14 2017
Mozilla appears to already expressed reluctance (towards changing their behavior; CSS changing seems unlikely IMHO.) I'll monitor the development on that front though...
,
Jul 16
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 17
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by sandeepkumars@chromium.org
, Jul 14 2017Labels: M-61 OS-Linux OS-Mac
Status: Untriaged (was: Unconfirmed)