Re: [svgwg] SVG2 path data coordinates are currently spec'd as integers.

I have been somewhat overambitious in wanting to "wrap up" the several grammar issues into one nice package with a bow on top, to present to all and sundry.  But I kept finding little nits requiring sanity evaluation: mine vs. draft.  e.g. number formats #331
.

The draft grammar has accumulated quite a number of changes over time, trying to respond to multiple ideas as they occurred.  
.

The first major reason to update the draft grammar was to move away from the SVG 1.1 ABNF format in order to agreeably share the common EBNF format seen with CSS and others.

Then there were a few bugs to be worked out in smaller changes.  As this issue and others have appeared since, we have seen there are more bugs to be fixed.

The last major change to the draft grammar was to address the work item called "segment-completing closepath", which fixes a lack not recognized since SVG 1.0 days.
.

Over this series of changes errors have crept in, sometimes merely because they were "thoughts in progress", like the wish to agree with the CSS number formats (which I only now understand is warranted #331) but which resulted in the broken number format mentioned in this issue.  And the other issue mentioned above (see also #324)  Unfortunately the aggregate result is a grammar that will not parse some currently legal constructs.
.

What I thought to do was introduce a PR in three parts or sets of interrelated changes.  Organizing into three parts best fits the three areas mentioned above.

Re-deriving an EBNF grammar from the SVG 1.1 grammar would create a "clean slate" that would make the following issue-specific changes much clearer.

Then addressing the individual bugs in the SVG grammar with small changes would allow problem description, change discussion, and acceptance of these small, separate issues to proceed smoothly.

And then applying the rather large change that supports the addition of "segment-completing closepath" would be done.
.

I wonder how best to proceed?  Should there be one PR with a large change (EBNF), then a number of small changes (bugs), then another large change (closepath)?  Or should there be three PRs in the same order, or many?

Two things are clear to me.  Amending the grammar from its current state would be very confusing, and would not help at all the "why this grammar rule?" questions of the future.  Second, the 'closepath'
work item is recent and [somewhat unclear](https://github.com/w3c/svgwg/issues/336), the change is also massive, and that grammar parsing is 'fiddly'.

Finally, Amelia's [comment above](https://github.com/w3c/svgwg/issues/335#issuecomment-317103852)  shows that tracking all these grammar specific issues is 'dispersed'.  Should there be a separate issue collecting all these together as work items or would a new Github label/tag be better?
.

.
More bits and pieces found while writing comment:
- Floating point number format discordance (SVG vs CSS vs browsers) #331
- C.4.2 out-of-range flag values note is invalid/unsupported, should be dropped #324  (refs: https://github.com/hughsk/svg-path-parser/pull/15)
- grammar for "closepath can substitute for final coordinate" is broken #325
- Show need for "segment-completing closepath" with curves/arcs #336


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

Received on Wednesday, 26 July 2017 21:27:48 UTC