You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a few problematic things about subgrid when it comes to Container Queries.
Single-axis size containment isn't meaningful for subgrids.
It needs some clarification in the spec, but if a subgrid has full size containment, its children also shouldn't affect the size of the parent grid's tracks (this is an implication of "lays out as if empty", taken to its full conclusion). But if you have just inline size containment, it's not clear what that means for the children. Their sizes don't just affect the subgrid's size; they affect the size of the parent grid's tracks, which can spill out to affect things far outside the subtree, in both axises.
Probably we want to define that either single-axis size containment gets "upgraded" to full size containment for subgrids, or that size containment makes you an independent grid, like layout containment does.
CQs can change whether a subgrid's item participates in the parent grid at all.
I don't think this is a true circularity, but @bfgeek tells me it's probably problematic for Chrome's impl if the set of grid items being looked at by the grid layout algo changes midway thru. This can't happen normally - for a CQ to depend on grid layout, it would have to be on a grid item, but then it can only affect the grid item's children, so the set of grid items being laid out doesn't change. But for subgrid this isn't true; its children are lifted into the parent grid for layout purposes, and a CQ can change whether or not they do so (it can make a child abspos, or turn a further nested subgrid child into an independent grid, etc).
Unsure what the right fix for this is.
The text was updated successfully, but these errors were encountered:
If a subgrid is a query container for size queries, then it also gets layout containment, so it establishes an independent formatting context and stops being a subgrid?
Oh, I'd missed/forgotten that size CQs require the element to be layout-contained as well as size-contained!
I believe that resolves both of these issues, then. You can still use a style query on a subgrid to affect whether a child is a grid item or not, but that doesn't depend on the mid-layout results so it won't change the set of grid items mid-layout.
May still need something for contain: inline-size, but TBH I'm not even sure how exactly that's supposed to affect a normal grid, even less so a subgrid.
There are a few problematic things about subgrid when it comes to Container Queries.
Single-axis size containment isn't meaningful for subgrids.
It needs some clarification in the spec, but if a subgrid has full size containment, its children also shouldn't affect the size of the parent grid's tracks (this is an implication of "lays out as if empty", taken to its full conclusion). But if you have just inline size containment, it's not clear what that means for the children. Their sizes don't just affect the subgrid's size; they affect the size of the parent grid's tracks, which can spill out to affect things far outside the subtree, in both axises.
Probably we want to define that either single-axis size containment gets "upgraded" to full size containment for subgrids, or that size containment makes you an independent grid, like layout containment does.
CQs can change whether a subgrid's item participates in the parent grid at all.
I don't think this is a true circularity, but @bfgeek tells me it's probably problematic for Chrome's impl if the set of grid items being looked at by the grid layout algo changes midway thru. This can't happen normally - for a CQ to depend on grid layout, it would have to be on a grid item, but then it can only affect the grid item's children, so the set of grid items being laid out doesn't change. But for subgrid this isn't true; its children are lifted into the parent grid for layout purposes, and a CQ can change whether or not they do so (it can make a child abspos, or turn a further nested subgrid child into an independent grid, etc).
Unsure what the right fix for this is.
The text was updated successfully, but these errors were encountered: