[css-anchor-position] should alignment safety consider the containing block? #10316
Labels
Comments
|
Proposal here is:
|
|
+1 to this proposal. There's definitely still use-cases for shifting within the IMCB, but I agree that most of the time it's the CB you're concerned with. |
1 task
|
I suspect that anything changing default alignment won't be web-compatible given how long folks have been relying on abspos layout. |
|
Yeah, I'm definitely comfortable with keeping the legacy behavior (aka skipping |
|
The CSS Working Group just discussed
The full IRC log of that discussion<keithamus> fantasai: this is a fun one, tackles two issues. Both anchor-center currently defined to changed the size, as well as to shift the alignment.<keithamus> ... so, the proposal is to remove the special sizing behavior from anchor-center. When neither unsafe nor safe is specified in the alignment property - in other words by default. And only when its not normal <keithamus> ... when the object is larger than the container we overflow away from the scrollable region <fantasai> https://github.com//issues/10316#issuecomment-2125437844 <keithamus> fantasai: So you're using the inset properties to create a containing block. If you're in abspos is small enough to fit in the IMCB you just do alignment as you specify <keithamus> ... If its larger than the IMCB we don't make it start aligned. If you hit the edge, say the right edge, the point were it's big enough to break out of the containing block we overflow in the opposite direction <keithamus> ... we overflow away from the scrollable region <keithamus> ... what this does - it gets you a very nice behavior for anchor center <TabAtkins> q+ <keithamus> ... that you keep the item visible. Try to center as much as possible but don't overflow unless you overflow the entire containing block <keithamus> ... shift the area as much as you can <fantasai> https://github.com//issues/10315 <keithamus> ... the other issue is this one <iank_> q+ <keithamus> ... a nice illustration somewhere <fantasai> https://github.com//issues/9960#issuecomment-1944518084 <keithamus> ... Una made a nice example of this <keithamus> ... the second behavior, not the one that resizes <Rossen4> ack TabAtkins <keithamus> TabAtkins: the only thing is you can't apply to normal. So locked in on compat. We might try to not do this on start/center/end <keithamus> ... there's large amounts of content that applies center to abspos things <keithamus> ... we might need to disallow on those based on compat <keithamus> ... we'll see how it goes when we deploy <keithamus> iank_: a little concerned web devs will get confused <keithamus> ... they say anchor center and the CB for some reason or another is small... I guess we might just have to teach webdevs to use unsafe anchor center <keithamus> ... which probably isn't the worst <Rossen4> ack iank_ <keithamus> ... but be prepared for likely recommending that heavily <keithamus> TabAtkins: if you have a weirdly small CB the position try stuff will be affected to. So they'll have to learn <keithamus> fantasai: the behavior we ideally wanted is you do safe centering if you're overflowing the edge of the scroll container <keithamus> ... but nobody has implemented that subtlety. <keithamus> iank_: that is long sailed <keithamus> ... means you invalidate a bunch of engine optimisations <keithamus> fantasai: but if we think people will want unsafe align for CBs not in viewport we could do that <Rossen4> ack fantasai <keithamus> ... probably a good starting point <fantasai> s/probably/but this is probably/ <keithamus> iank_: The problem with that is you'll need some way to expose magical default for those cases <keithamus> ... if we go down that path you'll need some magic alignment like overflow alignment <keithamus> ... I'm fine with this proposal but I suspect we might... people might be reaching for unsafe more. <keithamus> ... we should be cognizant that we might need to recommend it a lot more. <keithamus> Rossen4: any other opinions? <keithamus> PROPOSED: Accept proposal in 10316 but don't change normal behaviour when not using inset-area <keithamus> s/PROPOSED/fantasai: PROPOSED:/ <keithamus> RESOLVED: Accept proposal in 10316 but don't change normal behavior when not using inset-area <TabAtkins> So with this, I think Bikeshed's dfn panel behavior is just `inset-area: bottom span-right;` and *nothing else* |
fantasai
added a commit
that referenced
this issue
Aug 9, 2024
fantasai
added a commit
that referenced
this issue
Aug 10, 2024
… containing block for alignment safety. #10316
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Alignment has a concept of "safety", which is, we try to bias alignment in a direction that won't result in clipping the content. For
unsafecentering, we don't care; but forsafecentering we overflow away from the unscrollable region.For anchor positioning (and absolute positioning in general to be fair), there's two containers that are of interest: the inset-modified containing block, and the actual containing block.
Should the default behavior and/or the
safebehavior of an overflowing alignment bias towards staying within the containing block if possible, before finally overflowing the end/end edges?The text was updated successfully, but these errors were encountered: