- From: Dirk Schulze via GitHub <sysbot+gh@w3.org>
- Date: Thu, 10 May 2018 16:33:56 +0000
- To: public-svg-issues@w3.org
In addition to `<number>` values and path data, there is `<transforms>` as well. All three have different parsing rules in the spec. Path data as well as transforms have a more relaxed grammar than <number> and are consistent with each other. * transforms: https://codepen.io/krit/pen/rvdOQX * path data: https://codepen.io/krit/pen/wjmzzQ * number attributes: https://codepen.io/krit/pen/JvLrbv (x, y, width and height) | Relaxed Syntax | Number Attributes | Transform | Path Data | | ----------------- |:-----------------:| :---------:|----------:| | Adobe Illustrator | **yes** | **yes** | **yes** | | Edge | **yes** | **yes** | **yes** | | Safari | **yes** | no | no | | Chrome | **yes** | no | no | | Firefox | no | no | no | The parsing code for path data and transforms in WebKit is the same. Adapting the code to the relaxed syntax is straight forward and I do have an experimental build. If Edge is not willing to change their source code to the less flexible parsing rules then I'll land the patch in WebKit. Blink seems to use `SkParse::FindScalars` now so can't simply adapt the code from WebKit. I also care about consistency and interoperability. However, I am not sure how compatible CSS numbers can get to SVG numbers and IMO it is fine to have a difference between the two number types as long as the number parsing is consistent between all SVG attributes. If we allow a difference then I'd vote for the relaxed syntax. -- GitHub Notification of comment by dirkschulze Please view or discuss this issue at https://github.com/w3c/svgwg/issues/331#issuecomment-388108799 using your GitHub account
Received on Thursday, 10 May 2018 16:34:00 UTC