New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-transforms-1] SVG transform attributes: transforms don't need to be separated #3719
Comments
Interestingly, the SVG 1.1 grammar supports one or more We should definitely change to match reality where browsers are consistent (i.e., make the |
The CSS Working Group just discussed
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 |
Why there’s comma separators for CSS transform functions in the first place? Why not spaces, like The color functions now accept space-separated syntax, e.g. |
@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. |
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. |
https://drafts.csswg.org/css-transforms/#svg-transforms does not reflect implementations correctly.
Syntax says:
which requires a comma or a wsp between transform functions. Browsers do not require any separation between transform functions.
Example:
... does translate and scale the rect in Safari, Chrome and Firefox.
The text was updated successfully, but these errors were encountered: