[css-position] Weaker inset should depend on the wm of the containing block · Issue #5077 · w3c/csswg-drafts (original) (raw)

Consider

#target { position: relative; direction: rtl; inset-inline-start: 0px; inset-inline-end: 100px; }

text

According to the new CSS Postion, https://drafts.csswg.org/css-position-3/#relpos-insets

If neither is auto, the position is over-constrained; the computed end side value is ignored, and its used value becomes the negation of the start side.

So in this case we would ignore inset-inline-end: 100px and would instead use inset-inline-start: 0px; inset-inline-end: -0px (i.e. the box would not move).

But that's wrong. Because we are not using the writing mode of the box itself, but the one of its containing block, which has direction: ltr. So actually we ignore inset-inline-start: 0px and instead use inset-inline-start: -100px; inset-inline-end: 100px (i.e. the box moves 100px to the right).

This was right in the old CSS Postion and CSS2

If the direction property of the containing block is ltr, the value of left wins and right becomes -left. If direction of the containing block is rtl, right wins and left is ignored.

And basically the same for abspos. https://drafts.csswg.org/css-position-3/#abspos-insets says

the weaker inset is the end-edge inset.

But previously it was https://drafts.csswg.org/css-position-3/#abspos-old

If the values are over-constrained, ignore the value for left (in case the direction property of the containing block is rtl) or right (in case direction is ltr) and solve for that value.

I guess it's also the same for stickypos, https://drafts.csswg.org/css-position-3/#stickypos-insets

If this results in a sticky view rectangle size in any axis less than the size of the border box of the sticky box in that axis, then the effective end-edge inset in the affected axis is reduced

but here it's less clear since sticky didn't exist in CSS2, and the old CSS Position spec didn't take the wm into account. Stickypos seems broken in Chromium for over-constrained cases, but Firefox seems to consistently use the wm of the containing block.