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

I'm not going to argue for context-sensitive tokenisation, given pathdata is already marred by it.

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. But I respect your choice and won't press that further.

However if you _are_ going to do the higher level logic then maybe the solution is for SVG to provide a legacy parser that can hand off to your logic. Or for SVG to provide an algorithm that rewrites legacy pathdata into your canonical form.

FWIW your CSS-ified form seem fine for human readers, and web devs could do something like `pathdata.split(',').map( cmd => cmd.trim().split(/\s+/) )`, even if it's a sod for char-by-char parsers I tend to write. 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`)? 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?

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

Received on Friday, 1 December 2017 10:51:20 UTC