Re: [svgwg] Subtleties of the path data grammar (#752)

@tatarize I agree with your general idea: I find it more elegant to have the *grammar* itself be much simpler as you propose (e.g., not rejecting 1.0 as a flag, not rejecting -1.0 as an unsigned, and not  rejecting an incorrect number of arguments), and instead have the **operators** (M, L, etc...) be defined in such a way that they are robust to incorrect arguments (e.g., "stop processing path" if incorrect number of argument, or "take the absolute value" for arguments which are supposed to be non-negative).

Unfortunately, doing so would indeed be a breaking change, since as you remarked, things like `"...a25,25 0 1125,25 z"` are currently accepted, and couldn't be with a simpler grammar. I'm actually in favor of revamping the path-data syntax in a non-backward compatible way, but in this GitHub issue I wanted mostly to focus on fixing small unintentional errors that creeped in while rewriting the grammar from SVG 1.1 to SVG 2.

Just a few minor notes:

> No. Grammars should not reflect intent. 

I think you misunderstood what I meant by "intent". All I was saying is, for example: "The curent SVG 2 draft does not allow trailing whitespaces, while SVG 1.1 does allow them: is this an **intent**ional change?"

> the truth is regex is so ubiquitous that that is going to be how most everybody parses that grammar.

Actually, this is not how I'm parsing it. I do use a regex for "parsing the next number when I know that a number is expected", but I don't use a regex to split the path into commands. The latter is done with custom-made code, following the SVG spec very precisely: 

https://github.com/dalboris/vpaint/blob/696ba2ecee67f5e7086b32c18cdb15425b0bbe83/src/Gui/SvgParser.cpp#L339

For example, I do stop processing the path and issue an error if the character `+` or `-` is encountered while reading the first or second argument of an elliptical arc.

> The syntax doesn't matter that much, just that it's compact and easy to feed to well established parsers. [...] That sort of context sensitive parsing is horrible.

I agree that it's annoying that parsing arguments is context-sensitive (depends on the current operator and argument position), and it makes writing the parser harder. However, this context-sensitivity does make the syntax more compact, which was I believe the rationale for making this decision back in the days where compactness mattered more than today.


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

Received on Monday, 2 December 2019 18:18:08 UTC