Bug 15505 - Initial value of 'transform-origin' on SVG elements should be '0 0'
Initial value of 'transform-origin' on SVG elements should be '0 0'
Status: RESOLVED FIXED
Product: CSS
Classification: Unclassified
Component: Transforms
unspecified
PC All
: P2 normal
: ---
Assigned To: Dirk Schulze
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-10 19:05 UTC by Dirk Schulze
Modified: 2012-02-10 16:25 UTC (History)
4 users (show)

See Also:


Attachments
'transform-origin' with top left and 0 0 (740 bytes, text/html)
2012-01-23 17:47 UTC, Dirk Schulze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Schulze 2012-01-10 19:05:59 UTC
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.
Comment 1 Dirk Schulze 2012-01-10 19:07:30 UTC
Note that this bug is partly related to bug 15504 .
Comment 2 Aryeh Gregor 2012-01-23 17:03:04 UTC
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.
Comment 3 Dirk Schulze 2012-01-23 17:47:30 UTC
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
Comment 4 Dirk Schulze 2012-02-10 16:25:21 UTC
(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).