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

I think we're talking at cross purposes. I'm supposing that we're going to end up with two definitions of pathdata (one in the SVG standard and another in CSS) written in two different languages. I wanted to avoid that -- not least because the EBNF is unmanageable and it's now the only place SVG 2 uses EBNF at all.

With that in mind, I'll just clarify a few other points:

>>maybe the solution is for SVG to provide a legacy parser that can hand off to your logic. 

>It already does so, essentially.

The idea here was that the pathdata _grammar_ should be written once, using the rules in CSS Values and Units module. But that SVG would use its own legacy, layer-violating tokeniser instead of the one in the CSS Syntax Module.

> This is a levelling violation - the data has already been parsed by SVG at this point, the syntax is no longer relevant. The data is already in a nice parsed format inside the browser, usable by any part of the system.

And the thinking here was to operate on strings coming from the "d" attribute _before_ parsing. So we'd define an algorithm that would insert spaces, commas, and whatever else was needed to transform valid SVG-pathdata into valid CSS-pathdata. 

Again, the end game is to allow the SVGWG to make changes to the grammar using the rules in CSS Values and Units rather than hokey XML-EBNF. So this transform would be a way of specifying the legacy quirks, and not necessarily something browsers need actually do in practice.

> (There's no reason for webdevs to do any of this parsing on their own, anyway; that's what we now have the Typed OM for.)

The Typed-OM will be a godsend when it ships! But there's still a need to get at the individual segments of a path's `d` attribute.

> Dunno. I think it's better to have them be separate commands;

That's the choice that makes me feel warmest and fuzziestest. Hopefully that intuition is a product of experience.

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

Received on Friday, 9 February 2018 14:47:26 UTC