w3c / fxtf-drafts

Mirror of https://hg.fxtf.org/drafts
https://drafts.fxtf.org/
Other
68 stars 49 forks source link

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

Open tabatkins opened 1 year ago

tabatkins commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

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/