Re: [svgwg] Change arc grammar to coordinates rather than numbers and flags. (#755)

Oppose any breaking change. Leave the arc syntax as is. Require SVG output to add spaces as a safeguard.

There is nothing weird about a binary bit (0 and 1) being used for a boolean. Saying it would be OK to use `-0` for `0` would confuse existing SVG 1.1 parsers for no good reason. And why should anybody output `3` instead of `1` when he wants to signal true. Requiring the flag values to be exactly `0` or `1` is reasonable; it allows detecting bad files through syntactic errors.

Yes, the arc flag syntax is horrible. Yes, many people have been bitten by the quirky arc flag syntax (including me), and there are SVG 1.1 agents that parse the arc flags incorrectly. Yes, it would be nice if a tokenizer could be separated from the current parsing context, but that is not a big point when the grammar is shallow and likely subject to ad hoc parsing.

I disagree with the poster's notion of simple. It is already simple to parse the path. It might be nice, but we do not need the parsing to be trivial. Especially if it breaks other stuff.

Yes, some programs may want to use regular expressions to digest a path, but that does not mean those programs should be entitled to use trivial REs. It is not difficult to march down a path string. If I'm working on an arc, then I need to parse some types in a particular order. We do not need to say all those types must reduce to a floating point number.

The current arc syntax is not broken. The syntax may be unusual, but it is not incorrect. People may have missed some subtle issues about arc flags and spaces, but that does not mean the grammar is wrong. SVG 2.0 tools should accept SVG 1.1 files without complaining about the arc flag spacing issue. If SVG 2.0 uses a different syntax, then there's a compatibility issue. Making an SVG 2.0 parser accept different syntax based on the file's `version` would add more complexity and begs for more slightly broken implementations down the road. Keep the world simple by keeping the current arc syntax. Then SVG 1.1 and SVG 2.0 are consistent.

A better way to resolve this issue is to keep the SVG 1.1 arc syntax, but require that all SVG 2.0 output files put spaces between the flags. While we are at it, also require SVG output have spaces between each coordinate (i.e., no `M0.0.5` but rather `M0.0 .5`). In other words, allow quirky syntax on input but require reasonably delimited tokens on output. That would not be a breaking change for anybody. It would also discourage aggressive compression tools because they could not claim to follow the SVG 2.0 specification if they do not output the spaces. Existing SVG 1.1 programs, including programs that do not properly parse the arc flags, could display SVG 2.0 files. They would not be confused by introducing new syntax for flag value (e.g., `3`).

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

Received on Sunday, 7 June 2020 17:57:08 UTC