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

[motion-1] offset-anchor:auto is nonsensical #502

Open
tabatkins opened this issue Mar 3, 2023 · 3 comments
Open

[motion-1] offset-anchor:auto is nonsensical #502

tabatkins opened this issue Mar 3, 2023 · 3 comments

Comments

@tabatkins
Copy link
Member

The definition of offset-anchor: auto says:

Computes to the value from offset-position, provided offset-path is none and offset-position is not auto. Otherwise, computes to the value from transform-origin. When auto is given to offset-anchor, and offset-path is none, offset-position behaves similar to background-position.

This is word salad. If I attempt to interpret it as directly as I can, it gives wildly nonsensical results - it implies that offset-position: 100px 80px; offset-anchor: auto; will specify the anchor as being 100px to the right and 80px down from the element's top-left corner (while the offset-position is 100px/80px from the containing block's top-left corner). The 'transform-origin' part makes sense (at least in theory, see below), but then the next sentence (about an offset-path: none element!) is simply nonsense.

Like 'offset-position' before my recent rewrite in 2823e66, I suspect this section's text is entirely a leftover of when the offset properties were defined as a type of absolute positioning, rather than a type of transform, and if you didn't say anything specific about the path it defaulted to using 'offset-position' as an alternative to 'top'/'left'.

Also, 'transform-origin' is defined relative to the 'transform-box'. Motion doesn't have the same thing; if you just say "computes to the value of transform-origin" but transform-box is a non-initial value, you'll end up with the anchor point not matching the transform origin.


Suggested fix: offset-anchor: auto just sets the anchor point to be the same point as the transform origin. (This'll have to be specified in slightly more detail, since transform-origin doesn't technically define a point; instead it defines a pair or trio of lengths that feed into the transform matrix as a translate before and after the rest of the transforms. But this should be pretty easy to do.)

@tabatkins
Copy link
Member Author

After some archaeology, the "computes to the value from offset-position" was meant to give transforms a kind of background-position-like percentage behavior - offset-position: 100% 0%; offset-anchor: auto; would end up putting the element's starting position in the top-right corner, similar to how background-position: 100% 0% does for a background tile.

However, that's (a) already achievable with just slightly more manual work, by repeating the % yourself in both properties, and (b) as noted, completely nonsensical when offset-position is not written in percentages.

So yeah, my proposal stands; I think it's the only reasonable and consistent way to make this all work.

@tabatkins
Copy link
Member Author

Agenda+ to accept my proposal (that offset-anchor: auto reuses the 'transform-origin' point). The spec already contains this text, since what was there previously was nonsensical.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [motion-1] offset-anchor:auto is nonsensical, and agreed to the following:

  • RESOLVED: offset-anchor:auto uses transform-origin point
The full IRC log of that discussion <fantasai> TabAtkins: the def of offset-anchor: auto just copies over the offset-position value if that's not auto
<fantasai> TabAtkins: the reason for this was, if you specify offset-anchor: auto; offset-position: %
<fantasai> TabAtkins: then you would get a behavior similar to background--position
<fantasai> TabAtkins: where 100% put the element at the bottom right edge
<fantasai> TabAtkins: that's not unreasonable
<fantasai> TabAtkins: but if offset-position is not using percentages, you interpret 100px e.g. relative to the element's own box
<fantasai> TabAtkins: which means the element doesn't move at all!
<fantasai> TabAtkins: that's really weird behavior and definitely unintended
<fantasai> TabAtkins: it's also not necessary if we do the other fix if we do the other fix of starting from offset-anchor
<fantasai> TabAtkins: if you want bottom right corner, you set both to the same value
<fantasai> TabAtkins: very simple to get this behavior without the weird hack
<fantasai> TabAtkins: so propose to drop this behavior, offset-anchor: auto just uses tranform-origin
<fantasai> TabAtkins: since we need a default value, and good chance you'll want to use the same transform-origin as other transforms
<fantasai> florian: ???
<fantasai> TabAtkins: ....
<fantasai> astearns: any objections?
<fantasai> RESOLVED: offset-anchor:auto uses transform-origin point
<florian> s/???/in all cases, or just when offset-position is not using %?/
<florian> s/..../in call cases/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants