- From: James Stuckey Weber via GitHub <noreply@w3.org>
- Date: Fri, 11 Jul 2025 13:23:12 +0000
- To: public-css-archive@w3.org
> So "safe" is unsafe by design? My understanding is that on the end-side, `safe` and `unsafe` are identical. Only the unspecified neither shifts content on the end-side. > its trivial to overlap the anchor (which is bad IMO). > "safe" is defined to fallback to "start" alignment if it overflows - and in combination with fixedpos will result in unreachable content. I agree that both of these cases are bad. The question is which is worse, and the answer is it depends on the situation and the design of the anchor, and whether the positioned element's containing block is the viewport or clips the overflow. We could try to define more heuristics here, on whether the positioned element is clipped, or maybe try shifting in one axis at a time to see if it solves overflow without overlapping the anchor, but I'm not sure if that's possible or preferable. My preference is that the implicit safety in the case of `position-area` should be the same as the default in general (neither safe nor unsafe). I'm not sure that we can say the usage of `position-area` is significantly different than other use cases of overflowing aligned absolutely positioned blocks. I do think users are most likely to reach for `position-try` to handle these situations, but opting in to `unsafe` or `safe` behavior would also be useful. -- GitHub Notification of comment by jamesnw Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12466#issuecomment-3062332820 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 11 July 2025 13:23:13 UTC