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

> The benefits of a special casing pathdata would be for the SVG standard not to include a low-level parser and for CSS standards not having to clone the SVG grammar; the gain is for the web collectively.

Which spec the parser lives in doesn't make a difference; both technologies are being implemented by the same browser. There's no benefit to moving it from one place to another.

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

It already does so, essentially.

> Or for SVG to provide an algorithm that rewrites legacy pathdata into your canonical form.

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 that is indeed what happens - we don't have totally separate notions of "SVG path data" vs "CSS path data", it's just "path data"; there just happens to be a particular parser that can transform strings into path data, specified by SVG.)

> web devs could do something like `pathdata.split(',').map( cmd => cmd.trim().split(/\s+/) )`

Actually they can't. ^_^ Common problem with trying to do data-structure manipulation on the string level - you need to only split on *top-level* commas, but commas can appear inside of functions that are being used as values.  (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](https://drafts.css-houdini.org/css-typed-om/) for.)

----

Now for some responses on my syntax sketch:

> Are you going allow multiple path segments in a "command" (e.g. L 0 0 1 1) or require a separate command for each (i.e. L 0 0, L 1 1)?

Dunno. I think it's better to have them be separate commands; particularly when there's more than two arguments, it gets really difficult to immediately see the boundaries between commands otherwise. It's just a few characters extra for much improved readability.

> What about commands where closepath has been used to fill in missing coordinates? For example Q needs four coordinates as arguments, but Q 1 1,Z is legal under SVG 2, while Q 1 1, M 1 1 isn't. Are you going to handle that in the grammar? Will you allow the trailing Z in the command (as Q 1 1 Z, M 1 1) or require it be a separate command?

Hadn't thought about it yet, but a trailing Z sounds like it might be reasonable. I'll run thru the possibilities when I actually write this out as a proper proposal.

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

Received on Friday, 1 December 2017 19:08:36 UTC