794930 - transform-origin-x, transform-origin-y

Status: UNCONFIRMED

(Core :: CSS Parsing and Computation, enhancement, P3)

Description

[Sergii Iurevych]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1

Steps to reproduce:

Hey guys. Its handy to use transform-origin-x or transform-origin-y together with transform: scale(); sometimes.

But it doesn't work in Forefox. But it works just fine in webkit browsers.
Screenshot: https://img.skitch.com/20120927-8hu1rpsa27wuqu5jbjnyph1exp.png


Actual results:

Nothing happened. Firefox doesn't treat this property and shows error (see the screenshot)


Expected results:

Firefox should understand this property and move scaled block to a position I set in transform-origin-(x/y). See webkit implementation.

Comment 1

[Mardeg]

Is there a more recent version of the spec than at http://dev.w3.org/csswg/css3-transforms/#transform-origin as -x or -y doesn't exist in this one?

Comment 2

[Sergii Iurevych]

(In reply to Mardeg from comment #1)
> Is there a more recent version of the spec than at
> http://dev.w3.org/csswg/css3-transforms/#transform-origin as -x or -y
> doesn't exist in this one?
I haven't seen any :(

Comment 3

[Jean-Yves Perrier [:teoli]]

Independently of the merit of these two properties, a few points:

* This was discussed, without resolution, in the CSSWG weekly meeting on October 5th 2012. I don't have seen this discussed again since then (I may have missed it, though). 

* Since a few days a Google employee is pushing this in tutorials at webplatforms.org (w3c-blessed) as if it is a standard feature of css3 transforms, or as if it is good practice. I have fixed that documentation twice but this is likely to come back. If we want to support this, we should add it asap as I don't think that documentation of this kind should be spread with -webkit only prefixes recommended.

* It would be nice also to have a resolution before Webkit unprefix transforms (there is ongoing work on a big unprefixing, starting w/ gradients and transitions but animations and transforms are planned to come right after, which is very good news as Webkit is last major engine to unprefix), and to check that they do not unprefix by accident those two properties.

I've added dbaron, fantasai in cc/ so this get on their radar ;-)

Comment 4

[Sergii Iurevych]

(In reply to Jean-Yves Perrier [:teoli] from comment #3)
> Independently of the merit of these two properties, a few points:
> 
> * This was discussed, without resolution, in the CSSWG weekly meeting on
> October 5th 2012. I don't have seen this discussed again since then (I may
> have missed it, though). 
> 
> * Since a few days a Google employee is pushing this in tutorials at
> webplatforms.org (w3c-blessed) as if it is a standard feature of css3
> transforms, or as if it is good practice. I have fixed that documentation
> twice but this is likely to come back. If we want to support this, we should
> add it asap as I don't think that documentation of this kind should be
> spread with -webkit only prefixes recommended.
> 
> * It would be nice also to have a resolution before Webkit unprefix
> transforms (there is ongoing work on a big unprefixing, starting w/
> gradients and transitions but animations and transforms are planned to come
> right after, which is very good news as Webkit is last major engine to
> unprefix), and to check that they do not unprefix by accident those two
> properties.
> 
> I've added dbaron, fantasai in cc/ so this get on their radar ;-)
Good news, thank you for update!

Comment 5

[sky slot]

situs slot online terbaik https://skyslot88.com memberikan jackpot paling sensasional setiap harinya