- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 02 Apr 2026 23:56:50 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-conditional] Layout State Container Queries: `column-position` feature for flex/grid/multi-column layouts``, and agreed to the following: * `RESOLVED: Start working on spec for grid and tables in css-conditional-5` <details><summary>The full IRC log of that discussion</summary> <emilio> TabAtkins: container queries let us ask about lots of things in the container<br> <kizu> q+<br> <emilio> ... due to the restrictions we put<br> <emilio> ... one thing people ask for is column / rows<br> <emilio> ... it'd be fine for a child to ask the grid which column is it in<br> <emilio> ... main idea would be to allow us to query a few more layout aspects<br> <emilio> q+<br> <sgill> q+<br> <kbabbitt> q+<br> <iank_> q+<br> <lea> +1 yessssss<br> <emilio> ... main thing would be column / row positions in the various layout modes<br> <astearns> ack kizu<br> <emilio> kizu: yes +1 to the ask<br> <emilio> ... long-standing request<br> <lea> this is huge<br> <emilio> ... grid is probably one of the simpler ones<br> <emilio> ... until we introduce spanning<br> <lea> q+<br> <emilio> ... for other things like multicol or flex it's a lot more complicated<br> <emilio> ... would be nice to have<br> <emilio> ... regular containment would help<br> <emilio> ... size containment maybe then we can query the position of the flex item<br> <kizu> https://kizu.dev/position-driven-styles/#edge-detection (best viewed™️ in Chrome; I'll need to investigate why Safari is not doing the same; might be a problem in my code, but maybe something to report)<br> <emilio> ... right now it is possible to do * position animations because you can detect in view-timeline and so on<br> <emilio> ... this is something people want<br> <florian> q+<br> <emilio> ... would be nice to be able to pursue this in some way<br> <emilio> TabAtkins: for some layout modes children can affect your row, for those we'd need to have size containment<br> <kbabbitt> q-<br> <astearns> ack emilio<br> <TabAtkins> emilio: is the idea that the CQ now doesn't match just on the econtainer state, but also on the element it's querying from<br> <TabAtkins> TabAtkins: I don't understand<br> <TabAtkins> emilio: there's an example: column-position:last<br> <fantasai> TabAtkins: container is the grid item<br> <fantasai> emilio: ah, not the grid container<br> <fantasai> TabAtkins: otherwise it's circular<br> <fantasai> emilio: ok, that explains<br> <kizu> It could be something like a “layout query” with containment on items/etc being something that enables it maybe<br> <fantasai> emilio: so for grid in particular, there's no way that a layout change inside the item would change what column it ends up in<br> <fantasai> TabAtkins: correct<br> <fantasai> emilio: then that seems fine<br> <fantasai> TabAtkins: only grid can do that<br> <fantasai> fantasai: also table<br> <fantasai> TabAtkins: table cells don't care about their size<br> <fantasai> emilio: ok, seems doable...<br> <fantasai> emilio: a bit sketchy to ask based on state of ancestor ... but conceptually about the element ...<br> <astearns> ack sgill<br> <fantasai> sgill: I was just going to cover the last point<br> <fantasai> sgill: it works in grid, and maybe tables<br> <fantasai> sgill: but not in grid-lanes<br> <fantasai> TabAtkins: flexbox, grid-lanes, multicol, would need size containment so that children can't affect size<br> <astearns> ack iank_<br> <fantasai> iank_: Same concern wrt grid-lanes. Maybe carve out exception for explicit placement<br> <fantasai> iank_: for other layout modes, would need strict containment almost<br> <fantasai> iank_: because you would lay out often before you place them<br> <fantasai> iank_: to determine hypothetical size etc.<br> <fantasai> iank_: so it needs to be quite restrictive there<br> <fantasai> TabAtkins: I know it needs size containment. Idk about others<br> <fantasai> iank_: It needs style. Because it can affect the counters around it.<br> <fantasai> TabAtkins: if we need more containment, sure<br> <astearns> ack lea<br> <astearns> ack florian<br> <fantasai> florian: If we can get this to work in multicol, can we also get it to work on pages?<br> <fantasai> TabAtkins: detect what page?<br> <fantasai> TabAtkins: I think so<br> <fantasai> florian: there are uses for that<br> <fantasai> iank_: You'd need size containment<br> <fantasai> iank_: problem with fragmentation is that you also need to be monolithic<br> <kizu> q+<br> <fantasai> iank_: otherwise what happens if you're in 2 pages or 2 columns<br> <fantasai> florian: but not worse for pages than columns, so if can do for one do for both<br> <astearns> ack kizu<br> <fantasai> kizu: for multicol and grid and some other layout, might be one separate feature which would be very useful<br> <fantasai> kizu: if you have a grid inside multicol (!!!!) it would be very nice when it were fragmented to be able to switch the order of columns in different columns of multicol<br> <fantasai> kizu: Example: print-like page layout where you have gutters and page-spread with images on the outside of each page<br> <fantasai> kizu: It wouldn't change layout, just change the order<br> <kbabbitt> q+<br> <fantasai> florian: Yeah, flipping sides is a very common case.<br> <astearns> an+b column selectors might be a better fit for this?<br> <astearns> ack fantasai<br> <emilio> fantasai: for fragmentation, knowing something what page something is in<br> <emilio> ... requiring monolithic stuff is not going to get you what you want<br> <alisonmaher> q+<br> <emilio> ... being able to respond to the question would be useful even if fragmented<br> <emilio> ... you can tell which page you start on<br> <fantasai> TabAtkins: grid and table, simple and easy<br> <fantasai> TabAtkins: flexbox requires at least style and size containment, because size determines where you sit<br> <fantasai> TabAtkins: but can't fragment so can't live across lines<br> <Kurt> q+<br> <fantasai> TabAtkins: multicol and page layout, can live in multiple columns<br> <fantasai> TabAtkins: what if we do the easy ones first?<br> <fantasai> TabAtkins: grid + table<br> <fantasai> TabAtkins: then figure out flexbox<br> <fantasai> TabAtkins: then figure out design for fragments<br> <fantasai> TabAtkins: So for now would just add the grid and table version<br> <astearns> ack kbabbitt<br> <fantasai> kbabbitt: For fragmentation, wondering if we get into weird cases if e.g. left pages and right pages have different margins<br> <sgill> q+<br> <fantasai> florian: it's a giant can of worms, but I'm hoping that the containment constraints can help<br> <fantasai> florian: the Vivliostyle engine had features for this<br> <fantasai> florian: when you use these features, layout is not guaranteed to terminate<br> <TabAtkins> Ah, Flexbox and grid-lanes, rather. that's the second category. (layout-dependent but well-defined singular position)<br> <fantasai> florian: but we've solved that here, so can we extend to these use cases<br> <astearns> ack alisonmaher<br> <fantasai> florian: There really are a bajillion use cases<br> <fantasai> alisonmaher: In Grid you can have spanners, so you can be in multiple columns or rows. Is that not the same quest?<br> <fantasai> TabAtkins: you're right<br> <astearns> ack Kurt<br> <iank_> and that happens with tables as well.<br> <fantasai> Kurt: We wouldn't want the container query to set the grid area because then you have circularity<br> <iank_> (e.g. `<td colspan=2>`<br> <fantasai> TabAtkins: you don't have that because this only allows styling children of the grid item.<br> <astearns> ack sgill<br> <fantasai> sgill: Is there one caveat here with grid, where if you have several levels of nested subgrids, and then you change how it spans or something like that?<br> <fantasai> TabAtkins: I don't believe so?<br> <fantasai> TabAtkins: At least, rules for what is a valid container for you can make sure it's acceptable<br> <fantasai> iank_: I think you need "establishes an independent formatting context"<br> <fantasai> iank_: same as we do for container queries. subgrid can't participate in outer grid if it's a size container<br> <iank_> conditional-5 ?<br> <fantasai> https://www.w3.org/TR/css-conditional-5/<br> <astearns> ack fantasai<br> <iank_> conitional-6 !<br> <TabAtkins> fantasai: we do need to work on the spanning problem<br> <emilio> fantasai: re. spanning maybe you just return true on any?<br> <TabAtkins> TabAtkins: yeah figure out what queries we want<br> <TabAtkins> fantasai: also the syntax suggested is a bit complex, can do simpler than that<br> <TabAtkins> TabAtkins: agreed<br> <fantasai> astearns: Initial problems to chew over. Any objections to start working on this?<br> <fantasai> PROPOSED: Start working on spec for grid and tables in css-conditional-5<br> <fantasai> arronei: with likelihood that it goes to L6<br> <fantasai> RESOLVED: Start working on spec for grid and tables in css-conditional-5<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13729#issuecomment-4181061739 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 April 2026 23:56:51 UTC