- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Thu, 11 Feb 2021 14:44:10 +0000
- To: public-css-archive@w3.org
@dholbert > One possible constraint / concern here: the "search" here might need to be blocked from crossing boundaries of elements that form containing blocks for their fixed-position descendants (e.g. an element with `filter` or `transform` set to a non-default value). Do they need to be blocked when going up (i.e. the positioned element is a descendant of an element that forms a containing block for their fixed-position descendant) or also going down, i.e. when the positioned element is outside that subtree, but wants to be positioned relative to an element within that subtree? Although, I seem to recall `<dialog>`'s positioning was an exception to this anyway. > Similarly, it's worth thinking about how this would interact with / traverse `overflow:[hidden|scroll|auto]` and `contain:paint`. Yup, #5699 is about exactly that. While these would definitely be used together frequently, I think they are ultimately orthogonal issues. > (Though... is the intent here that the actual box-tree parenting of the positioned thing would be changed? i.e. does it just entirely "escape" any filters, transforms, `overflow` clipping, etc. that one of its nearby ancestors might otherwise impose on it? If so: then that would somewhat clarify how this would work in my previous comment. Though I suspect that reparenting would introduce other complications that I haven't thought through yet.) Ideally, yes. Whether it *needs* to or we can still cover enough use cases without this is yet unknown. -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5952#issuecomment-777511598 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 11 February 2021 14:44:12 UTC