- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Sat, 07 Oct 2017 17:48:21 +0000
- To: public-svg-issues@w3.org
> Is this intentional? Not particularly. It was just an attempt to move to an easier parser. Some minor differences aren't unexpected. Who's outputting numbers with a trailing . in their attribute values? > If so, what's the rational for changing it here and not on pathdata? Pathdata is *way* messed up, with *all sorts* of weird parsing quirks that aren't compatible with CSS parsing, and which tooling absolutely takes full advantage of to minimize the weight of large paths. Switching it to CSS-based parsing would be a massive, frustrating, confusing effort, and I'm not even 100% sure it *can* be done with perfect fidelity. (As a simple example, `h1v2` is a valid pathdata describing two commands each with a single argument. Under CSS parsing, it's a single ident token, which would have to be manually ripped apart back into commands.) > It's probably worth pointing out that SVG 1.1 is inconsistent with itself: it allows trailing dots in pathdata and the points attribute, but prohibits them on all other numbers. Interesting. This makes me more convinced that, absent any notable breakage as a result of this, we shouldn't worry about the change. --------- @zed-vector CSS specified its number syntax this way long ago. It's how people actually write numbers; the fact that some programming languages allow `1.` doesn't have any big impact here, because *nobody does that*. It's just a consequence of the way their grammar was put together, and someone going "eh, what's the harm". I doubt there's anything actually problematic about allowing it today - for that to be the case, it would require a number followed by a `.` for some other purpose (a class selector?), and a minifier relying on current parsing rules to safely concat them into `1.foo`. I don't think that happens anywhere right now, and I doubt it would happen in the future. So there's probably no web-compat that would *stop* us from making the change. But there's also no particular reason *for* us to make the change. It would come with costs for browsers (in parser work and testing work), but with basically no benefit to browsers or authors. This is distinct from the change to the `points` attribute, where there is still a cost, but the benefit is that the browsers can delete some custom parsing code and just reuse the existing CSS parser, and authors have a more consistent syntax story between `points` and all the other numeric attributes in the platform. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/svgwg/issues/331#issuecomment-334953690 using your GitHub account
Received on Saturday, 7 October 2017 17:48:12 UTC