Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Loirooriol opened this issue May 17, 2020 · 2 comments

Comments

@Loirooriol
Copy link
Contributor

Consider

#target {
  position: relative;
  direction: rtl;
  inset-inline-start: 0px;
  inset-inline-end: 100px;
}
<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 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.

@fantasai
Copy link
Collaborator

fantasai commented Sep 3, 2021

@Loirooriol Fixed. Please have a look and let me know if it's not yet correct!

@Loirooriol
Copy link
Contributor Author

Seems good but in the changes section you merged it into "Aligned resolution of auto margins on positioned boxes with [[CSS2]]" which may now need another title since this isn't related to auto margins. Also you didn't add a blockquote for the change in abspos.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants