MDN URL
https://developer.mozilla.org/docs/Web/CSS/Reference/Values/transform-function/rotate
What specific section or headline is this issue about?
Formal syntax
What information was incorrect, unhelpful, or incomplete?
Various SVG files use the syntax transform="rotate(angle, x, y)" and not just transform="rotate(angle)", to specify the center of 2D rotation (without depending on a separate setting of the transform-origin.
That is not documented, but visibly implemented in SVG renderers (e.g. in Chrome).
This is also missing in the Syntax summary of transform CSS property.
The MDN documentation only refers to "CSS Transforms Module Level 1".
In SVG, the center of rotation is defined since long in the standard DOM interface SVGTransform:
https://w3c.github.io/svgwg/svg2-draft/coords.html#VectorEffects
However it was removed in 2017 from "CSS Transforms Module Level 1" (without any justification), but is still present in wellknown brower implementations. Many existing and conforming SVG files (created before 2017) have used that syntax, and for that reason, implementations have kept the support for this 3-values rotate() syntax. It was still not reintroduced in "CSS Transforms Module Level 2" or SVG2. So the SVG specifications updates broke the compatilibility.
Specifying the center of rotation this is a VERY USEFUL shortcut, that avoids combining 3 transforms (a translation to the center, an angle-only rotation, and a backward translation), or a more complex "matrix" transform (using the "transform-origin" is a very bad idea in SVG, as its effect is global, and not local as expected in most situation; that modification makes SVG more complex to create or edit.
If the 3-values rotate() syntax is used, the separate setting of the transform-origin should be completely ignored, as the 2 additional values override this origin (the concept of separating a transform-origin does NOT work in practice, due to its scope: many shapes have internal definitions where you'll need rotations, that to be made independently of the outer rotation of a complete graphical object; dropping it from CSS specifications was a really bad decision of the W3C, inconsistant with what is still part of the standard SVGTransform DOM API made also by W3C, and with which all engines are building their SVG engines, the CSS specification allows restyling an SVG object, but NOT entirely to the point to completely break the SVG object! There's a isolation problem. That explains why Web browsers and SVG renderers have NOT dropped the 3-parameter rodate() property syntax, but consistently kept it.)
MDN should document that "legacy" syntax, that should have never been removed from W3C specifications, without any justification, and also without any mention in MDN. In my opinion, the W3C (or the author of the document about SVG transforms in CSS) just forgot to check its own SVG DOM API specification where it is still standard and well implemented and supported, only CSS specifications are broken!
What did you expect to see?
"rotate(angle, x, y)" -- compatibility with SVG implementations before 2017
Do you have any supporting links, references, or citations?
Many SVG documents which were created before 2017 and valid at that time, seem to be "broken" according to today's CSS specifications. But they are not, browsers jsut render them fine, unless they want to be "stricter" than what SVG already supports since long as part of its core standard. If we try to edit these working SVG files, they will be broken by editors that undesirably (and frequenetly silently) remove these valid 3-parameter rodate() transforms. In that case, to solve the issue, we have to manually edit the SVG files to change transform="rotate(angle,x,y)" into transform="translate(-x,-y)rotate(angle)translate(x,y)" (a very verbose and unnecessary syntax limitation).
Do you have anything more you want to share?
The same issue proably also affect the "skew" transforms, that also depend on an origin (but they are much more rarely used), where the SVG DOM API also has a standard support for specifying this origin, independantly of the outer style context).
MDN URL
https://developer.mozilla.org/docs/Web/CSS/Reference/Values/transform-function/rotate
What specific section or headline is this issue about?
Formal syntax
What information was incorrect, unhelpful, or incomplete?
Various SVG files use the syntax transform="rotate(angle, x, y)" and not just transform="rotate(angle)", to specify the center of 2D rotation (without depending on a separate setting of the transform-origin.
That is not documented, but visibly implemented in SVG renderers (e.g. in Chrome).
This is also missing in the Syntax summary of transform CSS property.
The MDN documentation only refers to "CSS Transforms Module Level 1".
In SVG, the center of rotation is defined since long in the standard DOM interface SVGTransform:
https://w3c.github.io/svgwg/svg2-draft/coords.html#VectorEffects
However it was removed in 2017 from "CSS Transforms Module Level 1" (without any justification), but is still present in wellknown brower implementations. Many existing and conforming SVG files (created before 2017) have used that syntax, and for that reason, implementations have kept the support for this 3-values rotate() syntax. It was still not reintroduced in "CSS Transforms Module Level 2" or SVG2. So the SVG specifications updates broke the compatilibility.
Specifying the center of rotation this is a VERY USEFUL shortcut, that avoids combining 3 transforms (a translation to the center, an angle-only rotation, and a backward translation), or a more complex "matrix" transform (using the "transform-origin" is a very bad idea in SVG, as its effect is global, and not local as expected in most situation; that modification makes SVG more complex to create or edit.
If the 3-values rotate() syntax is used, the separate setting of the transform-origin should be completely ignored, as the 2 additional values override this origin (the concept of separating a transform-origin does NOT work in practice, due to its scope: many shapes have internal definitions where you'll need rotations, that to be made independently of the outer rotation of a complete graphical object; dropping it from CSS specifications was a really bad decision of the W3C, inconsistant with what is still part of the standard SVGTransform DOM API made also by W3C, and with which all engines are building their SVG engines, the CSS specification allows restyling an SVG object, but NOT entirely to the point to completely break the SVG object! There's a isolation problem. That explains why Web browsers and SVG renderers have NOT dropped the 3-parameter rodate() property syntax, but consistently kept it.)
MDN should document that "legacy" syntax, that should have never been removed from W3C specifications, without any justification, and also without any mention in MDN. In my opinion, the W3C (or the author of the document about SVG transforms in CSS) just forgot to check its own SVG DOM API specification where it is still standard and well implemented and supported, only CSS specifications are broken!
What did you expect to see?
"rotate(angle, x, y)" -- compatibility with SVG implementations before 2017
Do you have any supporting links, references, or citations?
Many SVG documents which were created before 2017 and valid at that time, seem to be "broken" according to today's CSS specifications. But they are not, browsers jsut render them fine, unless they want to be "stricter" than what SVG already supports since long as part of its core standard. If we try to edit these working SVG files, they will be broken by editors that undesirably (and frequenetly silently) remove these valid 3-parameter rodate() transforms. In that case, to solve the issue, we have to manually edit the SVG files to change
transform="rotate(angle,x,y)"intotransform="translate(-x,-y)rotate(angle)translate(x,y)"(a very verbose and unnecessary syntax limitation).Do you have anything more you want to share?
The same issue proably also affect the "skew" transforms, that also depend on an origin (but they are much more rarely used), where the SVG DOM API also has a standard support for specifying this origin, independantly of the outer style context).