Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Transforms] transform-origin support #1964

Closed
cleercode opened this issue Jul 12, 2015 · 64 comments
Closed

[Transforms] transform-origin support #1964

cleercode opened this issue Jul 12, 2015 · 64 comments
Labels
Good first issue Interested in collaborating? Take a stab at fixing one of these issues. Resolution: Locked This issue was locked by the bot.

Comments

@cleercode
Copy link

Do Views have an equivalent of the CSS property transform-origin?

@chirag04
Copy link
Contributor

Not yet. As per my conversation with @sahrens and @vjeux We will need to add it to support perspective transformations.

Can you PR?

@chirag04
Copy link
Contributor

Reading from here: https://developer.mozilla.org/en-US/docs/Web/CSS/transform-origin

The transform-origin property lets you modify the origin for transformations of an element. For example, the transform-origin of the rotate() function is the centre of rotation. (This property is applied by first translating the element by the negated value of the property, then applying the element's transform, then translating by the property value.)

It seems you can still do it by just translating, then applying the transforms u want, and translating again. Does that solve?

@cleercode Would love to know the usecase and some example.

@brentvatne brentvatne changed the title Transform origin [Transforms] transform-origin support Jul 20, 2015
@brentvatne brentvatne added the Good first issue Interested in collaborating? Take a stab at fixing one of these issues. label Jul 20, 2015
@lelandrichardson
Copy link
Contributor

@cleercode @chirag04 I'm working on implementing this right now. Use case was something I wanted to rotate as if it the axis was the left, instead of the middle.

Implementing transform-origin in terms of pixels is super easy, but I'm trying to follow the spec for allowing percent and keywords such as left, center, etc. (which are just short hand for percent values).

Anyone have any guidance on how to accomplish the ability to use percentage values? It would need to require knowledge of the width/height of the element, which I don't think we have at this stage, right?

@chirag04
Copy link
Contributor

Nice. It would be interesting to have transform-origin. For now i would worry about having just numbers for it.

percent in general is not supported anywhere in react-native. Not sure why. We can implement percent as the next step i guess if required.

@lelandrichardson
Copy link
Contributor

I'll submit the PR for just the numbers, then we can talk about how to implement the rest of the spec with percents & keywords.

I imagine percent isn't implemented in RN because for the most part, flexbox prevents the need for it. This is an exception where the transform property is implemented outside of flexbox, but still might require some knowledge of the element's size...

@lelandrichardson
Copy link
Contributor

@chirag04 so there's a bit of a problem...

The way I've implemented this, I've basically set it up so that the user can specify x, y, z offsets from the "default origin", which is the middle of the element.

It looks like the w3c spec has the default set to the middle of the element, but the default is 50% 50% 0, not 0 0 0.

The way I have it working, if the user specifies transformOrigin: { x: 2, y: 2}, this results in the origin being 2px, 2px from the center, whereas the w3c spec puts transform-origin: 2px 2px as 2px, 2px from the bottom left of the element.

I'm happy to submit what I have, but this might present a problem as far as deviating from the expected behavior of an existing CSS property (as opposed to just not supporting it).

What do you think? @vjeux , perhaps you have some thoughts?

@sahrens
Copy link
Contributor

sahrens commented Jul 23, 2015

We should definitely match the web behavior where possible.

On Jul 23, 2015, at 4:36 AM, Leland Richardson notifications@github.com wrote:

@chirag04 so there's a bit of a problem...

The way I've implemented this, I've basically set it up so that the user can specify x, y, z offsets from the "default origin", which is the middle of the element.

It looks like the w3c spec has the default set to the middle of the element, but the default is 50% 50% 0, not 0 0 0.

The way I have it working, if the user specifies transformOrigin: { x: 2, y: 2}, this results in the origin being 2px, 2px from the center, whereas the w3c spec puts transform-origin: 2px 2px as 2px, 2px from the bottom left of the element.

I'm happy to submit what I have, but this might present a problem as far as deviating from the expected behavior of an existing CSS property (as opposed to just not supporting it).

What do you think? @vjeux , perhaps you have some thoughts?


Reply to this email directly or view it on GitHub.

@lelandrichardson
Copy link
Contributor

@sahrens agreed. does anyone have any thoughts on how to extract the width/height of the element in order to make this possible? From what I can tell, supporting transform-origin in this way is not going to be easily possible without completely changing the location of these calculations to somewhere where we have this information handy.

It's kind of a bummer, because implementing this as from the point of view of the center of the element, rather than the bottom left, is really simple.

@chirag04
Copy link
Contributor

@lelandrichardson Not sure if measure can help you extract the width/height of the element. Once you have that, i think it will be easy to do the manipulation.

@lelandrichardson
Copy link
Contributor

@chirag04 measure would certainly allow me to emulate the spec in user-land, but not sure how to use it here.

Without moving a ton of code, this is all basically taking place in precomputeStyle, which has no knowledge of what element it is applying the style to. We could pull this stuff "up" one level and go into computeUpdatedProperties, but doing something that drastic feels quite wrong to me at this stage.

@brentvatne
Copy link
Collaborator

Hi there! This issue is being closed because it has been inactive for a while.

But don't worry, it will live on with ProductPains! Check out it's new home: https://productpains.com/post/react-native/transforms-transform-origin-support

@alexHlebnikov
Copy link

Is there any way to emulate this? In my case I can't rotate icon properly without this property.

@lelandrichardson
Copy link
Contributor

@alexHlebnikov transform origin is implemented as a matrix transformation by a translation matrix to the resulting transform matrix. You can implement this currently by setting the transformMatrix style property, instead of the transform property, and doing the matrix operations yourself. If your transform is simple, this will likely end up as a fairly simple array of 16 numbers, some of which you will need to multiply appropriately from what you are using currently. Looking at the code in #2106 might help give you some context.

I talked to @vjeux about this PR some time ago and he seemed to agree that we could merge it in despite the difference from the web spec. If I get some time, I may try to revive the PR...

@afilp
Copy link

afilp commented Aug 17, 2016

Is this to be merged? I really needed it and using the matrix is not a nice solution. Thanks!

@faceyspacey
Copy link

+1

1 similar comment
@westcoastavgallery
Copy link

+1

@joshuasoehn
Copy link

+1 what's the status of this?

@Obooman
Copy link

Obooman commented Feb 25, 2017

+1

5 similar comments
@f0rr0
Copy link

f0rr0 commented Mar 1, 2017

+1

@utopianism
Copy link

+1

@btk
Copy link

btk commented Apr 12, 2017

+1

@dmbrowne
Copy link

+1

@rendomnet
Copy link

+1

@Jazz747
Copy link

Jazz747 commented Apr 26, 2017

+1 Come on, we need this badly!!

@micsun-al
Copy link

+1

2 similar comments
@kosiakMD
Copy link

+1

@Komeyl94
Copy link

+1

@Viral-Inc
Copy link

Viral-Inc commented Oct 23, 2017

+ >9000

@agrublev
Copy link

+1

8 similar comments
@deehuey
Copy link

deehuey commented Nov 13, 2017

+1

@muygrafico
Copy link

+1

@miguelocarvajal
Copy link

+1

@youpen
Copy link

youpen commented Jan 10, 2018

+1

@brayan9413
Copy link

+1

@patrickkempff
Copy link
Contributor

+1

@mtiziano
Copy link

+1

@gastonmorixe
Copy link

+1

@trsh
Copy link

trsh commented Feb 8, 2018

transformMatrix is listed as Deprecated! What now?

@sfatih
Copy link

sfatih commented Feb 13, 2018

@trsh as i can see in source of RN there is still transformMatrix. You can use it like this:
ss

@trsh
Copy link

trsh commented Feb 14, 2018

@sfatih yes, but using Deprecated features for a new project is not smart by nature. They can drop it in every next version.

@sahrens
Copy link
Contributor

sahrens commented Feb 14, 2018

@trsh: I think @sfatih is saying that you can use the non-deprecated transform: [{matrix: ...}] support instead of the deprecated transformMatrix to apply your own transform-origin equivalent to any transform you want to perform.

@trsh
Copy link

trsh commented Feb 14, 2018

@sahrens why would anybody mention something so obvious (that I can use transform and roll my own transform-origin logic)? All this topic is about, that we want "transform-origin" to be a in-the-box feature for react-native. Because it's a struggle to calculate those deltas and scale for example by left top corner. Matrix kind of was a small relief.

@zxcv551133
Copy link

+1

@filipef101
Copy link

@trsh How did you solve? what matrix did you apply?

@trsh
Copy link

trsh commented Mar 13, 2018

@filipef101 . No, I won't add deprecated features for a new project. I calculated it manually - I do scale, and then compensate (-translateX, -translateY) deltas from left and top. I will not share my code, as it's dumb and doesn't work very well. I suggest to take 3rd party math lib with matrix's calculate it your self, and then supply values for the transform. If you don't have fixed dimensions you will also need onLayout event to get needed dimensions.

@filipef101
Copy link

@trsh thanks! I actually solved with some trippy views and rotation, I actually applied the rotation using 3d matrix but it was the same not based on corner

@anish000kumar
Copy link

+1

2 similar comments
@barghi
Copy link

barghi commented May 18, 2018

+1

@michaeltrim
Copy link

+1

@victorwads
Copy link

+1

@facebook facebook locked as resolved and limited conversation to collaborators Jul 22, 2018
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Jul 22, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Good first issue Interested in collaborating? Take a stab at fixing one of these issues. Resolution: Locked This issue was locked by the bot.
Projects
None yet
Development

No branches or pull requests