This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The suggested modification of the user agent script suggest 'top left' as origin. That would be the same like 0% 0% of the objectBoundingBox. This doesn't reflect the current behavior on SVG where it is 0 0. Example: <rect x="100" y="100" width="100" height="100" fill="green"/> The transform-origin with the current behavior of SVG would still be 0 0. With the current description in CSS Transforms it would be top left of the objectBoundingBox, which is (100, 100, 100, 100). That means the origin is 100 100 as well.
Note that this bug is partly related to bug 15504 .
In the current CSS Transforms spec, "0 0" means the same as "top left" -- it's still an offset from the element's border box. There's no declarative syntax to achieve the SVG effect at all right now, as far as I can tell. So some syntax needs to be added to allow origins to be specified relative to the upper left of the initial containing block. Or a magical initial value (see bug 15504). But yeah, the current spec definitely does not reflect SVG behavior here.
Created attachment 1071 [details] 'transform-origin' with top left and 0 0 I can confirm that '0 0' means the same as 'top left' according the tested browsers: Opera, Firefox and Safari. IIRC CSS Shaders [1] tries to addresses this already with 'filter-margin'. We should take a look how CSS shaders specify this and may share the notation of borderBox. [1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html#filter-margin-property
(In reply to comment #3) > Created attachment 1071 [details] > 'transform-origin' with top left and 0 0 > > I can confirm that '0 0' means the same as 'top left' according the tested > browsers: Opera, Firefox and Safari. IIRC CSS Shaders [1] tries to addresses > this already with 'filter-margin'. We should take a look how CSS shaders > specify this and may share the notation of borderBox. > > [1] > https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html#filter-margin-property I added the following wording to the spec: "For SVG elements without an associated CSS layout box the <length> values represent an offset from the point of origin of the element's local coordinate space." I think that this fixes the problem with 0 0 and top left for SVG elements (that are not inline SVGSVGelements).