[css-transforms-1] SVG transform attributes: transforms don't need to be separated

[dirkschulze]

https://drafts.csswg.org/css-transforms/#svg-transforms does not reflect implementations correctly.

Syntax says:

transform
| transform comma-wsp transforms

which requires a comma or a wsp between transform functions. Browsers do not require any separation between transform functions.

Example:

<rect width="20" height="20" transform="translate(20, 20)scale(20)"/>

... does translate and scale the rect in Safari, Chrome and Firefox.

[AmeliaBR]

Interestingly, the SVG 1.1 grammar supports one or more comma-wsp tokens, but Firefox seems to be the only browser that allows arbitrary commas in between functions (Edge allows up to 2 commas, but no more, Chrome only allows zero or one).

We should definitely change to match reality where browsers are consistent (i.e., make the comma-wsp token optional in the grammar). For the inconsistent bit (excess separators), I would say the spec should be more restrictive (max one wsp*-comma?-wsp* sequence), so that content that matches the spec works in all browsers.

[css-meeting-bot]

The CSS Working Group just discussed SVG transform attributes: transforms don't need to be separated, and agreed to the following:

• RESOLVED: For SVG Transform attribute there is no requirement for space or comma between transform functions

The full IRC log of that discussion

<dael> TOpic: SVG transform attributes: transforms don't need to be separated
<dael> github: https://github.com//issues/3719
<dael> krit: There is a historical difference between SVG and CSS. If we jsut look at SVG there is a case of full interop that's not covered by spec. THer'es no space or comma between any transform list. Spec requires it but impl don't. I request we relax the syntax to follow impl
<dael> TabAtkins: THis falls out of CSS definition where you don't need spaces if you can distinguish
<dael> AmeliaBR: Not that simple b/c rest of syntax can't be desc with CSS syntax. Have special parsing for transform based on SVG1. THis happens to be where all browsers don't match SVG1 so might as well match other browsers
<dael> AmeliaBR: Found other weirdness that's inconsistent but I'm happy to ignore certain browsers allow mangled syntax. But if everyone supports we should include in spec
<rachelandrew> florian, I'm also an editor of page floats, if I can locate the list of resolutions I can at least do that
<dael> krit: Requested is For SVG Transform attribute there is no requiremenet for space or comma between transform functions
<dael> astearns: Just transform attribute?
<dael> krit: FOr CSS that falls out with the tokenizer so yes jsut for transform attribute
<dael> astearns: Objections?
<dael> myles: IN SVG transform definition jsut links to css
<dael> krit: Correct
<dael> AmeliaBR: There's a section in css transforms that gives special rules for parsing the attribute
<dael> krit: Link ^
<dael> astearns: It's in css draft where this is defined
<dael> krit: Yep
<dael> RESOLVED: For SVG Transform attribute there is no requirement for space or comma between transform functions

[valtlai]

Why there’s comma separators for CSS transform functions in the first place? Why not spaces, like translate(10px 20px)?

The color functions now accept space-separated syntax, e.g. rgb(0 0 0), which is more CSS-ish. Should we do the same for the transform functions?

[AmeliaBR]

@valtlai This discussion is about the legacy SVG syntax, which allowed either commas or spaces.

If you want to argue for loosening up the CSS syntax, that would be a separate issue.

I believe the reason to restrict things in CSS was about enforcing consistency: pick one syntax and stick with it! And (x,y) is a common idiom for describing vector translations in math, so that's probably why it was chosen. But you're correct that we've muddied the waters by switching the syntax for colors, based on the argument that commas should be reserved for lists.

[tabatkins]

Note that the transform functions were defined and shipped before @fantasai and I elucidated the "commas are for repeated lists, even in functions" principles.

The color-function switch happened at the same time as we added multiple other new color functions, and relaxes the arg-length requirements on a "no -a" versions of the existing functions; as a small part of a much larger shift, it wasn't a big deal. Switching transforms at this point would be solely a comma-removal, which isn't really worth the cost.