[csswg-drafts] [css-position] Weaker inset should depend on the wm of the containing block (#5077)

Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-position] Weaker inset should depend on the wm of the containing block ==
Consider

```css
#target {
  position: relative;
  direction: rtl;
  inset-inline-start: 0px;
  inset-inline-end: 100px;
}
```
```html
<div id="target">text</div>
```

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](https://drafts.csswg.org/date/2020-01-16T16:21:27/css-position-3/#rel-pos) and [CSS2](https://www.w3.org/TR/CSS22/visuren.html#relative-positioning)

> 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.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5077 using your GitHub account

Received on Sunday, 17 May 2020 21:10:38 UTC