- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 11 Feb 2021 22:54:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `@container queries with single-axis containment`, and agreed to the following:
* `RESOLVED: Define container queries in css-contain-3, editors L2 editors + Miriam`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Topic: @container queries with single-axis containment<br>
<ChrisL> git?<br>
<astearns> github: https://github.com/w3c/csswg-drafts/issues/5796<br>
<fantasai> miriam: Wanted to take the time to walk through presentation<br>
<miriam> https://slides.oddbird.net/csswg/f2f2102/<br>
<fantasai> miriam: slides here<br>
<fantasai> miriam: A number of use cases around container queries<br>
<fantasai> miriam: a few links ppl can follow for more complex and simpler use cases<br>
<fantasai> miriam: with MQ, we can change all instances of an element and will all change based on viewport<br>
<fantasai> miriam: breakpoint established, create a new layout for e.g. this card<br>
<fantasai> miriam: but even if those cards are in different parts of layout where they have different space available to them, will change based on viewport<br>
<fantasai> miriam: don't want to respond based on viewport though, want to respond based on size of container<br>
<fantasai> miriam: 2 proposals brought up last year<br>
<fantasai> miriam: dbaron's @container proposal<br>
<fantasai> miriam: and bkardell's switch()<br>
<fantasai> miriam: interesting tradeoffs, handle different cases<br>
<fantasai> miriam: not necessarily competing<br>
<fantasai> miriam: but main idea, I'm following up on dbaron's proposal<br>
<fantasai> miriam: it covers a lot of the use cases but requires establishing containers and being able to establish containers<br>
<fantasai> miriam: and have cards inside containers that can respond to containers they're in<br>
<fantasai> miriam: container can have nested containers<br>
<fantasai> miriam: each card is rsponding to its own container, even as size of window changes<br>
<fantasai> miriam: so to make that work, have to describe container itself<br>
<fantasai> miriam: to establish containers in this proposal<br>
<fantasai> miriam: what's required is having size and layout containment<br>
<fantasai> miriam: byt applying size and layout containment, we can establish them as containment contexts<br>
<fantasai> miriam: a bit of a problem here also noted by dbaron<br>
<fantasai> miriam: size containment is very invasive<br>
<fantasai> miriam: if always have to explicitly set height and width, doesn't work for many use case<br>
<fantasai> miriam: need 1D containment<br>
<fantasai> miriam: developing prototype to prove that can work<br>
<fantasai> miriam: for inline axis<br>
<fantasai> miriam: for block axis, a bit more complicated<br>
<bkardell_> q+ if there are use cases for block axis even?<br>
<fantasai> miriam: if that doesn't work, then width/height can't be made to work because can be iether inline or block<br>
<fantasai> miriam: most essential however is inline-size<br>
<fantasai> miriam: dbaron's syntax looks like this<br>
<astearns> zakim, open queue<br>
<Zakim> ok, astearns, the speaker queue is open<br>
<fantasai> @container <selector> (<query>) { <rules> }<br>
<fantasai> miriam: If we have to be explicity about which containers we're looking at, less flexible<br>
<bkardell_> q+ if there are use cases for block axis even?<br>
<fantasai> miriam: really what we want is to say h2 or card can respond to whatever container it's in, and wherever we put it can respond<br>
<bkardell_> q+ i<br>
<fantasai> miriam: modular that way<br>
<fantasai> miriam: proposal is to remove the selector block<br>
<fantasai> miriam: just describe the query, not the container that it will match against<br>
<fantasai> miriam: and instead we use the DOM tree to find the container that we're in<br>
<bkardell_> q- i<br>
<bkardell_> q+<br>
<fantasai> miriam: so each card looks up its ancestors to the first container that has the limits we're querying<br>
<fantasai> miriam: code example [slide]<br>
<fantasai> @container (min-width: 40ch) { ... change grid template ... }<br>
<fantasai> miriam: that would work in any container<br>
<fantasai> miriam: h2 is good example of why this needs to be very modular<br>
<fantasai> miriam: might want to use h2 in any container, not defining specifically how one component work<br>
<fantasai> miriam: tree can be nested however<br>
<fantasai> miriam: if both are h2, they each look up their nearest ancestor container and respond to size of that container<br>
<fantasai> [shows tree]<br>
<fantasai> miriam: rules in @container apply when aancestor with appropriate containment, and query applies<br>
<fantasai> miriam: query against actual values on element, not the viewport, can look at e.g. actual size of the element<br>
<fantasai> s/size/font size/<br>
<fantasai> miriam: Could we have queries that respond to font size on container / element?<br>
<fantasai> miriam: containment is external<br>
<fantasai> miriam: so can't query e.g. size available to you in a grid track, always querying the element itself<br>
<fantasai> miriam: that's one place where the switch proposal would be a bit more powerful<br>
<fantasai> miriam: but this is also something we can work around by adding an intermediate layer<br>
<fantasai> miriam: add an element that's a container as the grid item, put the card inside<br>
<fantasai> miriam: some talk of alternate syntax based on pseudo-class<br>
<fantasai> miriam: :container(query)<br>
<fantasai> miriam: Some downsides and some positives<br>
<fantasai> miriam: adding in nesting, becomes quite similar<br>
<fantasai> miriam: this provides a few use cases that the @container wouldn't<br>
<fantasai> miriam: a lot of other open questions<br>
<fantasai> miriam: some of them already have issues, some don't<br>
<fantasai> miriam: we can dig into any of that later<br>
<fantasai> miriam: links to explainer, issue, TAG review<br>
<fremy> q+<br>
<Rossen_> ack bkardell_<br>
<astearns> https://github.com/oddbird/css-sandbox/blob/main/src/rwd/query/explainer.md<br>
<fantasai> bkardell_: I think this is great<br>
<ChrisL> q+<br>
<fantasai> bkardell_: question when presenting, are there known use cases for block direction?<br>
<fantasai> miriam: think would be similar to viewport height use cases<br>
<fantasai> miriam: those are rare<br>
<fantasai> bkardell_: I found use cases for thing you're doing first, easier part with very strict containment<br>
<fantasai> bkardell_: plenty for inline-axis<br>
<fantasai> bkardell_: much more than I thought there were initially<br>
<fantasai> bkardell_: I actually agree with you that nesting is super-important to work out for a whole bunch of things<br>
<astearns> tag review: https://github.com/w3ctag/design-reviews/issues/592<br>
<fantasai> bkardell_: we're making a lot of choices differently; nesting is big deal, one of the biggest things we could work on<br>
<fantasai> bkardell_: would like us to prioritize<br>
<fantasai> bkardell_: also want to express that this is awesome, and would love to coordinate some more between Igalia and Google who are doing this work<br>
<fantasai> bkardell_: to make alignments<br>
<Rossen_> q?<br>
<fantasai> bkardell_: some similarities in internals that would be good to sort out<br>
<fantasai> bkardell_: some opportunities to sugar things as well<br>
<Rossen_> ack fremy<br>
<fantasai> fremy: very good proposal, like the feel of it<br>
<fantasai> fremy: I am wondering if makes sense to say that everything containing something becomes a container<br>
<fantasai> fremy: sometimes you need that for perf reasons, be weird if that also changes layout in CSS<br>
<fantasai> fremy: maybe add a new value to get the behavior<br>
<fantasai> fremy: Something that you can do with this that can't otherwise<br>
<fantasai> fremy: can use these containers to set display:none to things<br>
<fantasai> fremy: which would change counters etc.<br>
<fantasai> fremy: maybe we need a bit more containment that just size?<br>
<fantasai> fremy: Unsure also about how easy to implement<br>
<fantasai> miriam: Anders and Rune have been working on that, idk if they're here<br>
<fantasai> fremy: globally I like the idea, if I make one change to proposal, if we don't use selectors about what is a container, then need to have an explicit way to indicate which is a container<br>
<fantasai> miriam: solution you mentioned, of explicit value for contain, that would address the issues you raised<br>
<fantasai> chrishtr: was this about counters?<br>
<fantasai> miriam: potential of accidentally creating a container somewhere<br>
<fantasai> miriam: I haven't found use cases where you want to skip a containment box<br>
<fantasai> miriam: but being more explicit can be handled by a specific value<br>
<fantasai> miriam: also way it relates to counters, might need style containment<br>
<fantasai> miriam: bulky if contain: inline-size layout style<br>
<fantasai> miriam: maybe can be combined into that explicit value<br>
<fantasai> fremy: exactly what I had in mind<br>
<Rossen_> ack ChrisL<br>
<fantasai> leaverou2: I wanted to say, 2 syntaxes proposed at-rule vs pseudo-class<br>
<fantasai> leaverou2: is pseudo-class actually doable?<br>
<fantasai> leaverou2: they match at an earlier stage, can't match at computed value time<br>
<fantasai> TabAtkins: generally speaking yes<br>
<argyle> q+<br>
<fantasai> TabAtkins: theoretically don't need to if there's not a computation loop<br>
<fantasai> TabAtkins: could do another pass later, but usually want to avoid<br>
<fantasai> leaverou2: thought significant pushback against 2 passes<br>
<fantasai> fremy: but in this case we need it anyway<br>
<fantasai> leaverou2: if both fair game, I think pseudo-class syntax allows combining with other selector criteria if both doable<br>
<fremy> s/fremy/florian/<br>
<Rossen_> ack argyle<br>
<fantasai> argyle: so many fun use cases, breakdown so good<br>
<fantasai> argyle: one of the difference between switch and container syntax<br>
<fantasai> argyle: question of what am I targetting<br>
<fantasai> argyle: switch can know its own size<br>
<fantasai> argyle: that's an important use case<br>
<fantasai> argyle: container might have 20 items in it, what's the space I'm given?<br>
<fantasai> argyle: not sure how to wrestle with those thoughts<br>
<fantasai> argyle: pseudo-class selector might be opportunity to specify which container<br>
<fantasai> argyle: what if want immediate parent?<br>
<fremy> btw, this won't require just two pass, it would require one pass per element, but each pass might require a layout pass in between<br>
<una> +1 to the individual container<br>
<fremy> I should just say that on call, nevermind<br>
<fremy> q+<br>
<fantasai> miriam: wouldn't be immediate parent, would be nearest contained parent<br>
<fantasai> argyle: what if you want container a few steps up?<br>
<fantasai> miriam: Question has come up, but haven't come up with any use cases for it<br>
<fantasai> miriam: wrt switch, agree, that's why these are parellel solutions<br>
<fantasai> miriam: with switch(), element queries itself, but is limited in how much can be changed<br>
<fantasai> miriam: can't change width based on width<br>
<fantasai> miriam: limited properties, but querying actual self space<br>
<fantasai> miriam: but with this one querying something external, but can change anything inside it<br>
<fantasai> miriam: address differnet use cases with a bit of overlap, both worth pursuing<br>
<Rossen_> q?<br>
<Rossen_> ack fremy<br>
<fantasai> fremy: Wrt lea's multiple passes<br>
<fantasai> fremy: You don't need to have multiple passes<br>
<fantasai> fremy: need one pass for element<br>
<fantasai> fremy: but need to do layout<br>
<fantasai> fremy: [missed]<br>
<fantasai> fremy: One case I feel a big issue<br>
<fantasai> fremy: proposal of containing only in one dimension<br>
<una> q+<br>
<fantasai> fremy: that's the only case you have to do layout and then styling inside container<br>
<fantasai> fremy: then have to do layout of everything again<br>
<fantasai> fremy: that could change size of container<br>
<fantasai> fremy: that one is much more tricky, and could do layout many times<br>
<fantasai> fremy: multiplied by nesting of containers<br>
<florian> s/[missed]/you only need to layout outside the container in one pass, and inside in the second pass, so it's not really two passes/<br>
<astearns> s/[missed] you just have to stop and start at container boundaries (instead of two pass)<br>
<fantasai> fremy: bigger problem, not easy to solve<br>
<Rossen_> q?<br>
<fantasai> fremy: if you have only one, unsure if there's any restriction that we don't have to do the layout of everything in a nested way, so maybe file an issue that and think about it<br>
<fantasai> miriam: issue opened already<br>
<fantasai> Rossen_: OK, good presentation, what do you want to ask WG?<br>
<fantasai> miriam: support for going forward, and feedback like I'm getting<br>
<fremy> s/[missed]/between the styling passes<br>
<fantasai> una: For slide 15, you have great diagram of initial container and then blue and pink items wider and vertical items<br>
<fantasai> una: theoretically same component<br>
<fantasai> una: What I see is that you set containment once, on parent<br>
<fantasai> una: each individual element querying?<br>
<fantasai> miriam: matched with this code [other slide]<br>
<Rossen_> ack una<br>
<fantasai> miriam: containment on sidebar, main, grid-items<br>
<fantasai> miriam: those 5 containers<br>
<fantasai> miriam: single card component appears in each container<br>
<fantasai> miriam: each one querying its most immediate container<br>
<fantasai> una: so containment on immediate parent ,and cna nest<br>
<fantasai> una: ancestor. You pick the closest ancestor with container<br>
<fantasai> una: in theory, could you set containment on body?<br>
<fantasai> una: and have on any child<br>
<fantasai> miriam: it would act similar to a media query<br>
<emilio> q+<br>
<fantasai> miriam: main advantage would be responding to actual font size not environment font size<br>
<fantasai> miriam: if ancestor ...<br>
<bkardell_> "root container"<br>
<fantasai> miriam: no container, maybe fall back too root to be smarter<br>
<fantasai> una: is it necessary to set containment on children?<br>
<fantasai> miriam: in order to query something's width, we have to set containment on it<br>
<fantasai> miriam: in order to avoid the loops<br>
<fantasai> miriam: if only set on body, we can't query the width of the grid item<br>
<Rossen_> ack emilio<br>
<fantasai> emilio: There were some versions of proposal that support selectors<br>
<fantasai> emilio: what happens with Shadow DOM there is a bit weird<br>
<fantasai> emilio: stuff like ancestors might not even be in rendering tree at all<br>
<fantasai> emilio: but might be DOM ancestor, ancestor of shadow host<br>
<fantasai> emilio: descendant combinators wouldn't work<br>
<fantasai> emilio: that probably involves more complexity<br>
<fantasai> emilio: we can probably come up with some reasonable thing to do, but...<br>
<Rossen_> q?<br>
<fantasai> Rossen_: hear a lot of support and excitement about this<br>
<fantasai> Rossen_: anyone opposed to adopting it?<br>
<fantasai> chrishtr: Would be new module, not addition to existing?<br>
<leaverou> +1 from Chris and Lea<br>
<argyle> q+<br>
<fantasai> miriam: potential for it to happen in Containment and Conditional, or could be its own<br>
<fantasai> argyle: pushback I've heard is that 1D doesn't sound as useful as 2D?<br>
<fantasai> argyle: if I can't know the width and height of something together, how can I make a good decision?<br>
<fantasai> miriam: you can, but would have to contain both<br>
<fantasai> miriam: you have to contain whichever dimension you query<br>
<Rossen_> ack argyle<br>
<fantasai> miriam: but containing both dimensions doesn't address a lot of use cases<br>
<fantasai> miriam: block-only containment is hard, we're unsure if we can do it<br>
<fantasai> Rossen_: ...<br>
<fantasai> florian: If we want to pursue this, need to pursue 1D containment on its own<br>
<fantasai> florian: that goes in css-contain<br>
<fantasai> florian: but needs further work<br>
<fantasai> florian: rest of it [missed]<br>
<fantasai> miriam: that's being worked on at Chrome<br>
<fantasai> Rossen_: Spec-wise, where are we in 1D containment<br>
<fantasai> florian: discussion in GH that it's likely to be possible, but that's as far as we got<br>
<Rossen_> q?<br>
<fantasai> bkardell_: 1 issue with some back and forth, that's all<br>
<fantasai> bkardell_: I agree would make sense that it goes there, and is prerequisite for the rest<br>
<fantasai> bkardell_: but no reason not to figure out where the rest of it goes<br>
<fantasai> bkardell_: rest of it, if we put it in a spec, would be dependent on 1D containment<br>
<TabAtkins> fantasai: My suggestion would be to put the whole thing as Contain 3, and we can figure out exactly where bits go later as we work on it.<br>
<TabAtkins> fantasai: Either way, 1d-containment needs to be in Contain<br>
<Rossen_> ack fantasai<br>
<TabAtkins> fantasai: Draft as a diff spec for now, you can pull things back if you need, otherwise l3 will be all CQs<br>
<bkardell_> is that where we would want to put switch too?<br>
<nicole> It's so exciting that this is happening. :)<br>
<fantasai> florian: Unsure if contain-2 is that close to CR, but also not opposed to what fantasai said<br>
<una> +1 to the excitement :D<br>
<bkardell_> +1 excitement<br>
<jensimmons> +1<br>
<argyle> 🎉<br>
<leaverou> +1 excitement!<br>
<fantasai> Rossen_: Proposal here is to add this to css-contain-3<br>
<fantasai> Rossen_: Only question I have is, who works on this besides Miriam?<br>
<tantek> +1 progress!<br>
<fantasai> florian: I'm already editing level 1 and 2, so happy to tag along with 3<br>
<fantasai> florian: will focus on containment rather than querying, but<br>
<fantasai> Rossen_: so level 2 editors + Miriam<br>
<bkardell_> q+<br>
<una> WOOO!<br>
<chrishtr> Excellent!!!!!<br>
<fantasai> RESOLVED: Define container queries in css-contain-3, editors L2 editors + Miriam<br>
<nicole> 🎉<br>
<bkardell_> q- I guess if it is going to not happen, but my question above seems relevant<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5796#issuecomment-777846985 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 22:54:47 UTC