Created attachment 118455 [details] Initial patch to gather some feedback This initial patch allows the CSS parser to handle SVG transform syntax, which is different from the CSS ones. Here are some differences: - SVG uses unit-less values defaulting to certain units: translate(10, 10) - arguments can be separated by space: translate(10 10) - functions can be separated by comma: rotate(10), translate(10, 10) - function name can be separated by white-spaces from the open parenthesis: translate (10 10) - rotate can have 3 arguments Also, CSS implementation uses doubles to keep the values (SVG uses floats), leading to one SVG test failing due to rounding: (difference for calculating the bounding box for scaling at 0.01 a 100px rect)

Comment on attachment 118455 [details] Initial patch to gather some feedback I already talked with Raul about this approach. Just commenting to this bug for the history. I think it would be great to align up the SVG Transforms parser with the CSS Parser. That will make it possible to handle the SVG "transform" attribute like a CSS property later. That means we would remove the SVG Transforms parser and the control of SVG Transforms would go to CSS like it is done for other styling properties in SVG today. Of course more it needs to be done on the SVGDOM later, but this is a promising first step. I suggest to create a new patch just with the CSS Parser changes for comma less arguments on functions. In a separate patch and bug report we should think about adding two new optional arguments to the CSS rotate function: rotate(<angle>[, <length>, <length>]) to match the specification of SVG Transforms. We don't have to modify SVGTransforms at the moment. It would be better to concentrate on the CSS parser and add a lot of new tests.

Created attachment 122034 [details] Allow unitless values, comma separated functions and space separated arguments in CSS transform parser

Comment on attachment 122034 [details] Allow unitless values, comma separated functions and space separated arguments in CSS transform parser I don't get this. We can't allow unitless values in transforms in an HTML context, only when they are being used in SVG.

(In reply to comment #4) > (From update of attachment 122034 [details]) > I don't get this. We can't allow unitless values in transforms in an HTML context, only when they are being used in SVG. As far as I know unit less values were a consensus of the editors of CSS Transforms? If we differ on unit parsing between SVG and HTML content we might confuse web developers. Also it would need to partly split the parser for HTML and SVG. I opened a bug report on W3C. Maybe we can discuss how we should proceed there: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15507

(In reply to comment #5) > (In reply to comment #4) > > (From update of attachment 122034 [details] [details]) > > I don't get this. We can't allow unitless values in transforms in an HTML context, only when they are being used in SVG. > > As far as I know unit less values were a consensus of the editors of CSS Transforms? That is not my understanding. > If we differ on unit parsing between SVG and HTML content we might confuse web developers. Also it would need to partly split the parser for HTML and SVG. > > I opened a bug report on W3C. Maybe we can discuss how we should proceed there: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15507 Thanks.

(In reply to comment #5) > I opened a bug report on W3C. Maybe we can discuss how we should proceed there: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15507 That bug is about comma separation, not lack of units.

(In reply to comment #7) > (In reply to comment #5) > > > I opened a bug report on W3C. Maybe we can discuss how we should proceed there: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15507 > > That bug is about comma separation, not lack of units. Oh sorry, my fault. We didn't have a unit less specific bug report. I opened a new bug report: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15525

The CSS WG and SVG WG decided to modify the syntax of SVG to support CSS syntax. This patch is doing the other way around. Therefore I close this bug.