- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Dec 2020 01:01:10 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-contain-1] do we need size containment in a single dimension to enable container queries?`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-contain-1] do we need size containment in a single dimension to enable container queries?<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/1031<br> <dael> miriam: The context is in thinking about container queries and starting from dbaron initial proposal a few years back<br> <dael> miriam: Easy to imagine how it works with full size containment, but doesn't work for most cases. Works in app-like cases but otherwise falls apart.<br> <dael> miriam: prop is 1d containment so can contain width of element and query against that but allow height to adjust.<br> <dael> miriam: Several cases where height of children changes width of ancestors. Scrollbars and % in padding<br> <dael> miriam: A lot of talk about that making it quite difficult<br> <dael> miriam: anders and I have been pushing on that.<br> <dael> miriam: Going through the ideas backwards b/c 2nd one is thinking through how to address issues as they arrise. If we want 1d can we always trigger scrollbar on ancestors, resolve % to auto<br> <dael> miriam: Not full proposals, but want to push conversation forward<br> <dael> miriam: That's a start on how might address issues as edge cases so 1d containment would work<br> <dael> miriam: anders proposed the pinky-promise approach. Idea here is what if we don't require containment on container queries and we resolve the query as if we have full size containment but allow you to make changes so you get different final size then reported<br> <florian> q+<br> <dael> miriam: trade offs between but not exclusive of each other. A lot more to resolve on both. Anders isn't here but that's basic context<br> <dael> florian: Author usibility I think pinky-promise works. Cases where children effect cross axis size are rare and easy to avoid.<br> <Rossen_> ack florian<br> <dael> florian: Concerned about implications on impl b/c makes layouts effectively stateful. if doing partial layout you have to do a relayout to figure out size if you hadn't instearted the children you did insert. Order becomes meaningful as well which brings us back to having to do a layout of the anti-page<br> <bkardell_> q+<br> <dael> florian: Not impossible, but could be expensive. I'm concerned. THe plug the leaks one by one seems more possible. We haven't come up with so many examples. We've so far had 2. Maybe can plus one by one<br> <dael> florian: Seems that by far dominant of 1d is query inline size, not block. The leaks for inline and block are not same. Easier to plug inline leaks. If we jsut worry about those maybe slightly easier problem<br> <dael> bkardell_: In the pinky-promise thing doesn't that wind up negative auto-height?<br> <Rossen_> ack bkardell_<br> <dael> florian: No, the pinky-promise case you do a container query against width and then you say I won't do anything in layout what would change the width of the parents. As long as you don't have the cases that is does change width of parents everything is fine<br> <dael> miriam: One other complication is inside of floats that shrink wrap, container query would return 0 but layout is quite a bit different<br> <dael> florian: Yeah. But for shrink-wrap this is fundamentally problematic.<br> <miriam> +1<br> <dael> florian: If there is a use case for that it's a whole different can of worms<br> <dael> Rossen_: We're at time. not sure if we have a resolution we could call. I would urge you to continue discussing on GH<br> <iank_> I'm somewhat not convinced the pinky-promise will yeild the results web-developers expect.<br> <dael> TabAtkins: Not looking for resolution yet, just general information<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1031#issuecomment-737590518 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 3 December 2020 01:01:12 UTC