- From: Dirk Schulze via GitHub <sysbot+gh@w3.org>
- Date: Thu, 10 May 2018 19:31:08 +0000
- To: public-svg-issues@w3.org
@fsoder Here the code from Blink which is still identical to the code in WebKit: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/svg/svg_parser_utilities.cc?sq=package:chromium&l=90 So Blink definitely does not use CSS parsers for the `transform` attribute and as far as I can see path data isn't either. Blink also supports `1.e2` which is not supported on `<number>` in SVG nor `<number>` in CSS. You are right that both, Blink and WebKit, have a compatibility/quicks mode for CSS parsing. I am fine if this gets specified and addresses the current behavior which is the relaxed syntax on transforms and path data as it seems to be used for pure length/number based attributes. I checked adding a space after `10.` and it indeed fails parsing in WebKit and Blink. Given that `1.e2` works, this seems to be a bug though. Adobe Illustrator is not going to be more restrictive on parsing numbers in any of the number-taking attributes. There is a huge number of SVG files that get produced for print or set top boxes and never gets opened in a browser and authoring tools have to take those into account too. -- GitHub Notification of comment by dirkschulze Please view or discuss this issue at https://github.com/w3c/svgwg/issues/331#issuecomment-388160260 using your GitHub account
Received on Thursday, 10 May 2018 19:31:10 UTC