Closed Bug 1209061 Opened 4 years ago Closed 3 years ago

transform-origin not applied correctly on svg content

Categories

(Core :: SVG, defect)

defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: erik, Unassigned)

References

(Blocks 2 open bugs, )

Details

(Keywords: testcase)

Attachments

(4 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.99 Safari/537.36 Vivaldi/1.0.283.8

Steps to reproduce:

1. Load http://jsfiddle.net/fs6cLt38/1/

Sidenote: Chrome currently gets the the same test wrong if transform is an attribute instead of a property (see http://jsfiddle.net/fs6cLt38). Please don't make the same mistake, it should be a true presentation attribute :)


Actual results:

The black diamond shape is misplaced (due to transform-origin being applied incorrectly).


Expected results:

There should be no red in the page.
Blocks: 779683
Component: Untriaged → SVG
Keywords: testcase
Product: Firefox → Core
It works if add transform-box:fill-box; to the style
@Alice(In reply to Alice0775 White from comment #1)
> It works if add transform-box:fill-box; to the style

Why is 'fill-box' not the (default) used value for elements without layout boxes? As this example shows, making the used value be 'view-box' produces a non-intuitive result.

Anyway, I can take my feedback to the style and svg mailinglists.
Firefox 41, 42 require the svg.transform-box.enabled pref to be set to true to support transform-origin and transform-box

Firefox 43 supports transform-origin without a pref but only supports transform-box when the svg.transform-box.enabled pref is set to true.

In release builds the prefs are false by default.
I'm having a similar issue with transform-origin in Firefox in that it isn't being handled the same in FF as compared to modern browsers Chrome, Safari, and even Opera. I recently posted the following to a dev group I'm a part of and it was suggested that I add my notes here for your review...I hope that the contribution helps you in your endeavors. Thanks!

---

Hi! Does anyone know how to animate SVGs in Firefox in a way that works around the transform-origin bug and keeps animations consistent across all browsers?

Please only suggest tested code. I would like something that works as far back as FF version 39 but if you understand and have working proof of the fix for version 41 I can deal. 

My site for visual example: http://dev.jan-michael.net

My working code https://github.com/jmwii1981/hello_world/tree/master/css
(.../hello_world/css/jan-michael.css OR .../hello_world/css/jan-michael.scss - whichever you find more clever)
(In reply to jmwii1981 from comment #5)
> I'm having a similar issue with transform-origin in Firefox in that it isn't
> being handled the same in FF as compared to modern browsers Chrome, Safari,
> and even Opera. I recently posted the following to a dev group I'm a part of
> and it was suggested that I add my notes here for your review...I hope that
> the contribution helps you in your endeavors. Thanks!
> 

You'd need to set transform-box: fill-box; and also enable the svg.transform-origin.enabled pref (Firefox 41, 42) or the svg.transform-box.enabled pref (Firefox 43).

At the moment Chrome seems to use fill-box by default which is incorrect per the current specification (https://drafts.csswg.org/css-transforms/#transform-box although comment 4 suggests that the specification may change to match Chrome. This is precisely why transform-box support is still behind a pref in Firefox.
What exactly does this code look like to make FF behave like all the other browsers?

I'm using CSS animations, not javascript, so there is no "set" command.

Enable the svg.transform-origin.enabled pref? Does this mean enabling it in FF? You can't ask thousands of end users to do that.
We need the specification to stabilise per comment 4. Once that's decided we'll turn on the pref.
Duplicate of this bug: 1209853
Duplicate of this bug: 1229699
Obviously it is much wiser to do what Chrome does while the spec is still a draft (the only mention I could find of it is on MDN)

The default is completely unintuitive. In addition to that - there is no real way to 'fix' this in all current versions of Firefox. I think everyone would be fine if you still had those settings disabled, but kept the default in a way which does not break websites.
(In reply to yem_salat from comment #11)
> Obviously it is much wiser to do what Chrome does while the spec is still a
> draft (the only mention I could find of it is on MDN)
> 
> The default is completely unintuitive. In addition to that - there is no
> real way to 'fix' this in all current versions of Firefox. I think everyone
> would be fine if you still had those settings disabled, but kept the default
> in a way which does not break websites.

Why is it much wiser (let alone obviously so) to copy a vendor implementation that deviates from the spec? And as far as fixes for all versions of Firefox go, the spec is still in draft, so you shouldn't be using these properties in production anyway.
(In reply to yem_salat from comment #11)
> 
> The default is completely unintuitive.

So go get the specification changed.
> Why is it much wiser (let alone obviously so) to copy a vendor implementation that deviates from the spec?
Because the spec is not decided yet, and because it goes against the way that all other elements work.
Do I really need to elaborate why the new behaviour is not intuitive to someone who has been using 3d transforms for past couple years?


> the spec is still in draft, so you shouldn't be using these properties in production anyway
That is exactly what I am doing - I am using 'transform-origin' which is a w3c recommendation, and I expect it to work the same way across all elements, ignoring unsupported properties.
Transform-origin has been available for a while now: http://www.w3.org/TR/css3-transforms/#transform-origin-property

> So go get the specification changed.
I don't need to, its not even a 'working' draft yet. What are you gonna say if w3c changes their mind?


Also, what is exactly the purpose of 'svg.transform-origin.enabled' pref? So far it seems like a rather useless setting.
Sorry, just wanted to add that I did read the discussion on the w3c panel, and I do understand where they are coming from with the transform-box property, but I still think it is best to keep websites from breaking until everything is finalized.
As the spec draft mentioned, https://www.w3.org/TR/css-transforms-1/#transform-rendering, transform-origin should render into the local coordinate system is given by the element’s transformation matrix. Currently, FF Nightly 49 uses the world coordinate system (canvas).
(In reply to Daosheng Mu[:daoshengmu] from comment #19)
> As the spec draft mentioned,

That's the wrong/obsolete spec. https://drafts.csswg.org/css-transforms/#transform-box is the right spec. Note the following text:

For SVG elements without an associated CSS layout box, the used value for border-box is view-box.
Robert, you are right. In current spec, "for SVG elements without an associated CSS layout box, the used value for border-box is view-box." I agree this is very unintuitive for users. I look forward the spec getting changed.
It fair enough to say it works if you set "transform-box:fill-box;" however, I am using the current version of firefox 46.0.1 and transform-box is not available without turning on the flag.

When will it be enabled in public builds? and therefore be production ready?

The project I am working on uses a third part system that uses a custom build of fennec.

Can I assume that if we ask them to provide us with a version that has the flag svg.transform-box.enable true that it is aleast technically possible?

Cheers
(In reply to rburnie from comment #22)
> It fair enough to say it works if you set "transform-box:fill-box;" however,
> I am using the current version of firefox 46.0.1 and transform-box is not
> available without turning on the flag.
> 
> When will it be enabled in public builds? and therefore be production ready?
> 

Comment 6 already explains what the issue is. We don't know whether Chrome or the spec will change.
The spec currently says "For SVG elements without an associated CSS layout box, the used value for border-box is view-box." It has to be that way to avoid breaking huge amounts of SVG out there, so I don't think we can or should change that. Let's close this as INVALID and get our transform-box implementation shipped so that authors can get their content to behave the way they want it to.
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
Making a note here that Firefox 55 now has support for the "transform-box" CSS property. Setting it to "fill-box" will mimic that of Chrome with respect to transform-origin in SVG trees.

transform-box: fill-box;
transform-origin: center; /* or transform-origin: 50% */

Related: https://bugzilla.mozilla.org/show_bug.cgi?id=1208550

Actually the original example works the same both in Chrome 73 and in FF 65. Well not exactly the same but close enough.

You need to use transform-box:fill-box; for both to get what you expect. Attaching screens.

Attached image chrome_73_fill-box.png
Attached image FF_65_default.png
Attached image FF_65_fill-box.png
You need to log in before you can comment on or make changes to this bug.