search

w3c / fxtf-drafts

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

[motion-1] offset-position:auto has bad behavior #501

Open tabatkins opened 1 year ago

tabatkins commented 1 year ago

Currently, the spec for offset-position: auto specifies that the starting point for the offset path is the top-left corner of the box.

When this interacts with a non-auto 'offset-anchor', this gives bad behavior - it becomes impossible to start a path from the box's original position. Instead, the box shifts slightly, to align its anchor with where its top-left corner was originally.

The first example in https://drafts.fxtf.org/motion-1/#offset-position-property shows that this is indeed the intended behavior - the green box is first abspos'd 80px to the right and 100px down, then its anchor-position (which is center) kicks in and the box shifts 40px left and 50px up so that its center point is at that (80, 100) point.

I suspect this is a weird leftover of when this spec was defined in terms of abspos rather than transforms. The (imo) clearly superior behavior for offset-position: auto would be to just use the anchor position itself, so at offset-distance: 0% the box just... stays exactly where it is.

Do we think this is possible to change? The only offset path that pays attention to offset-position is ray(), so maybe the change is minimal in practice?

(Again, the core use-case for ray() is positioning things around a round clock face. Using position: absolute; top: 50%; left: 50%; offset-anchor: center; would work for this in the current spec; in the fixed spec you'd instead write offset-position: center; offset-anchor: center;. The old way would still mostly work, it would just start the rays slightly off-center.)

tabatkins commented 1 year ago

Agenda+ to confirm my proposal above - offset-position: auto resolves to the point in the element specified by offset-anchor, rather than the top-left corner of the element, so the box doesn't move from its current position by default.

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: When using offset-position: auto; and offset-anchor
<fantasai> TabAtkins: offset-position means "start from box's position"
<fantasai> TabAtkins: offset-anchor says which point you put on the path
<fantasai> TabAtkins: as written, offset-position uses top left corner
<fantasai> TabAtkins: offset-anchor uses center
<fantasai> TabAtkins: means that by default you get this slight shift
<fantasai> TabAtkins: seems bad and weird
<fantasai> TabAtkins: I think this is one of the things that fell through the cracks
<fantasai> TabAtkins: my proposal is when offset-position: auto is used, we start from the offset-anchor point
<fantasai> TabAtkins: so wherever the box is, that's where it will start from
<fantasai> TabAtkins: and will start moving from that point instead of shifting a little bit
<fantasai> TabAtkins: The examples show that the current behavior is expected, but seems bad
<fantasai> +1
<fantasai> PROPOSED: offset-position: auto honors offset-anchor
<fantasai> florian: Only bit that worries me is that we don't know why we decided the way we did
<fantasai> TabAtkins: reason why was probably because we based it on the position stuff
<fantasai> TabAtkins: if you wanted a ray from the center, easiest way is left: 50%; top: 50% which puts your left top in the center
<fantasai> TabAtkins: to actually center your box, you'd have to use a transform hack
<fantasai> TabAtkins: with previous resolution, you could just say ray(at center) and get the behavior you want
<fantasai> TabAtkins: I think this was just confluence of a slightly weak feature and interaction with position
<fantasai> florian: seems convincing enough
<fantasai> RESOLVED: offset-position: auto uses offset-anchor point
<fantasai> github: https://github.com/w3c/fxtf-drafts/issues/501