- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 01 Apr 2026 18:55:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid-3][masonry] Clarify that optimized track sizing is expected in grid containers with subgridded masonry`. <details><summary>The full IRC log of that discussion</summary> <kbabbitt> alisonmaher: clarifying question<br> <kbabbitt> ... in grid-lanes spec, we have virtual items as an optimization for track sizing<br> <kbabbitt> ... for subgrid to work in grid-lanes, concept of placing every item in every possible position<br> <kbabbitt> ... question of whetehr virtual items need to be extended to grid as well<br> <kbabbitt> ... to support subgrid in grid-lanes container<br> <kbabbitt> fantasai: Feel like that's an impl question<br> <kbabbitt> [crosstalk]<br> <kbabbitt> fantasai: if you want to virtual aggregation as part of grid track sizing that's perfectly fine<br> <kbabbitt> ... is there a question about behavior changes here?<br> <kbabbitt> alisonmaher: don't think there is, just a matter of having in spec that this is also needed to be extended more generally to full grid spec as opposed to being grid-lanes specific<br> <kbabbitt> ... because of cross subgridding behavior<br> <kbabbitt> fantasai: as long as spec is clear about expected behavior, optimization differences are up to impls<br> <kbabbitt> Rossen: Is there a spec change that would result in behavioral differences?<br> <kbabbitt> alisonmaher: don't think there is a behavioral change<br> <kbabbitt> TabAtkins: still a little confused baout this, given that grid-lanes defines layou tin terms of virtual items, why would submasonry not use this?><br> <kbabbitt> alisonmaher: could be implied, issue was opened because it was tied to the diff spec<br> <kbabbitt> ... could interpret it as applying to that scenario as well, maybe fine as-is<br> <kbabbitt> sgill: that whole section of the spec is supposed to be purely optimization<br> <kbabbitt> ... whether an impl does or doesn't follow that specific portion, result should be the same<br> <kbabbitt> TabAtkins: that's the intention, maybe a note that if there's a difference should be an error<br> <kbabbitt> alisonmaher: point is that grid will need some way of doing this place every item in every position for subgridded items<br> <kbabbitt> ... as long as it's clear in the spec, optimization option other option apply to track sizing<br> <kbabbitt> fantasai: optimizations are generally not a spec issue<br> <Kurt> q+<br> <kbabbitt> ... if behavior is dfferent then that's a spec issue<br> <kbabbitt> ... doesn't seem like there's one here<br> <kbabbitt> alisonmaher: fine closing no change<br> <Rossen> ack alice<br> <Rossen> ack alisonmaher<br> <Rossen> ack Kurt<br> <kbabbitt> Kurt: if the optimized track sizing is supposed to match it does say to increase contribution<br> <kbabbitt> ... last resolution has a step to say for each virtual item increase contribution accordingly, does that still hold?<br> <kbabbitt> ... sounded like we decided only to use virtual items baseline for placement not for track sizing<br> <kbabbitt> TabAtkins: good question<br> <kbabbitt> fantasai: we didn't resolve that<br> <kbabbitt> fantasai: spec is already correct, requires you to resolve considering baselines<br> <kbabbitt> Kurt: but for each virtual item's contribution<br> <kbabbitt> fantasai: what it's try8ing to say is, when assembling virtual item, it has not just size but aligned baselines<br> <kbabbitt> ... figure out colletive baseline position<br> <kbabbitt> ... then you have a virtual item and treat it like any other item in grid sizing algorithm<br> <kbabbitt> ... which considers size and baseline position vs other items<br> <kbabbitt> ... have to do some amount of shimming<br> <kbabbitt> ... already required in the spec<br> <Kurt> https://www.w3.org/TR/css-grid-3/#track-sizing-performance<br> <kbabbitt> Kurt: because it's classified as a vritual item, it says determine baseline of virtual items, is that correct?<br> <kbabbitt> fantasai: [reads from spec]<br> <kbabbitt> ... multiple baselines in virtual items<br> <kbabbitt> ... because an item can have central baseline, alphabetic baseline, etc.<br> <kbabbitt> ... have to figure out what is the baseline of that item by accumulating items into virtual item<br> <kbabbitt> ... put them into a track by themselves align them to each other, what are start and end edge and my baselione<br> <kbabbitt> ... tyhat's step 2<br> <kbabbitt> ... step 3 is put copies of virtual items wehre they're neeeded along with real items<br> <kbabbitt> ... then run track sizing which runs baseline alignment<br> <kbabbitt> Kurt: so you re-shim?<br> <kbabbitt> fantasai: yes beacuse you're doing track sizing<br> <kbabbitt> ... you're taking the idea that we have this shim, but it's the same shim, it's not the same shim<br> <kbabbitt> ... using a shim in step 2<br> <kbabbitt> ... then in step 3 pretend it doesn't have a shim anymore, put in trqack and shiim everything<br> <kbabbitt> Kurt: feels like shim in step 2 and 3 are related reading it, but they're not<br> <kbabbitt> ... might need a note<br> <kbabbitt> fantasai: we can find a way to make that less confusing<br> <kbabbitt> Rossen: do we need to resolve or take an action item to add clarification?<br> <kbabbitt> fantasai: it's the structure of the sentence. [reads from sperc]<br> <kbabbitt> ... next step is just run track sizing, doesn't talk about shims<br> <kbabbitt> Rossen: let's take an action item to clarify<br> <fantasai> https://www.w3.org/TR/css-grid-3/#track-sizing-performance<br> <kbabbitt> ... Kurt can suggest language to clarify what fantasai was describing<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11347#issuecomment-4172287377 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 April 2026 18:55:25 UTC