[motion-1] Make offset-position more specific

[danielsakhapov]

Currently offset-position says that when it's specified with position it:

Specifies the initial position, with the the containing block as the positioning area and a dimensionless point (zero-sized box) as the object area.

But it's not clear if it should calculate the initial position from the computed position (left + top properties, for example) + offset-position. Or it should be containing block (0, 0) + offset-position, ignoring the left, top properties.

And taking the note into account:

This is similar to absolute positioning, except that offset-position does not prevent boxes from impacting the layout of later siblings.

I think it needs to be specified how it should interact with other properties like left, top, right, bottom. For example, if I the size of the box is determined by all of that properties, but offset-position is specified, how they should interact?

[BorisChiou]

The description of offset-position is really unclear to me as well.

Also, the description of offset-position says:

Specifies the initial position of the offset path. If position is specified with static, offset-position would be ignored.

These words sound like we shouldn't take offset-position into account if position is static. However, The spec example 10 applies offset-position with static position. I am confused about this example.

cc @tabatkins for this issue because we have some wpt for offset-position and so we probably have to make spec words clearer, for interop 2023.

[tabatkins]

Yeah, I have absolutely no idea what that spec text is trying to say or why it's trying to say it. The entire property seems very confused; it appears to think that 'offset' is a form of absolute positioning, rather than a transform.

Here, let me just go rewrite the whole thing to make sense. brb

[danielsakhapov]

Thanks, Tab!

From what I've understood from Eric is that in case of offset-position being specified, we should ignore previous position of the element (e.g. left and top properties) and just start offseting it from 0, 0 of containing block.

But in this case, do we really need this property if we can have the same effect of having the start position of our path from left and top properties?

Maybe consider deleting it at all? Or start the offset not from 0, 0 of containing block, but rather from the computed position of the element?

[tabatkins]

It's properly got nothing to do with top/left; the default starting point is just "where the box is at the end of layout" (then adjusted by offset-anchor to find the precise point in that box). offset-position is useful because it means you don't need to manually position the box where you want it to start using normal layout, you can just specify it directly. In particular, it makes it much easier to start the box centered in its container - 50% 50% for both offset-position and offset-anchor. (Note that the only reliable way to put an arbitrarily-sized box in the center of its container currently requires you to use transform (left: 50%; top: 50%; transform: translate(-50%, -50%);), which is applied after offset, so it doesn't work here. ^_^ When impls get place-self working correctly on abspos that'll change, but this is still a nice convenience.)

[tabatkins]

Ah you know what, iirc the Motion spec used to be defined on top of abspos, rather than being a transform; offset-position (and -anchor) were never properly rewritten after the change.

Okay, so summary of changes in 2823e66:

• Clarified that offset-position only applies to offset paths that don't predefine their initial position (that is, only ray()).
• Removed any mention of 'position' from the values, since it's irrelevant.
• Removed the text about non-auto causing a stacking context/containing block; that behavior is caused by a non-none 'offset-path' itself, not by 'offset-position'.

While doing this I realized that the specified behavior of auto (particularly when combined with a non-auto offset-anchor is nonsensical; I'll raise a separate issue for this.

Does this look good to y'all?

[BorisChiou]

Looks good to me for this simplification. Thanks.