Re: [csswg-drafts] [css-grid] Ability to clamp track spanning (#5852)

The CSS Working Group just discussed `[css-grid] Ability to clamp track spanning`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> miriam: especially ins ituation where you use auto-fit/fill repeating grid, there's a pain point where you want element to span multiple columns *if avaialble*, but not add new columns if they're not needed<br>
&lt;TabAtkins> miriam: This is a problem with auto grids, you have to reach for MQ/CQ, figure out the breakpoints, and use that to change the span size<br>
&lt;jensimmons> YYEEEESSSSS This is such a pain to do manually.<br>
&lt;TabAtkins> miriam: There's been many requests for this, been chatting with Elika, wanted to push a proposal for fixing this<br>
&lt;TabAtkins> miriam: Suggest a `span(min, max)` function<br>
&lt;TabAtkins> miriam: so `span(1, 3)` - for the sake of determining what columns are *needed* we use the min, and for the sake of placement we use the max<br>
&lt;TabAtkins> miriam: happy to bikeshed the specifics, but wanted to know if we can start working on it<br>
&lt;TabAtkins> fantasai: in favor generally, i think the syntax is reasoanble<br>
&lt;dbaron> s/placement we use the max/placement we use the max.  Could maybe also be an `all` value./<br>
&lt;TabAtkins> fantasai: currently span is a keyword, this would shift it to a function, we could maybe make the second argument optional<br>
&lt;rachelandrew> +1 in general, again something people really would like to do<br>
&lt;TabAtkins> fantasai: one naming concern is that "all" would span only the explicit tracks, not the implicit<br>
&lt;iank_> this adds a bunch of complexity with mansonry, and they willl span a variable amount of columns<br>
&lt;TabAtkins> ???: so in order to determine implicit gridlines you'll use the min span<br>
&lt;TabAtkins> ???: but for placement you use the max - how does that work?<br>
&lt;TabAtkins> miriam: You'd use max, clamped by the number of columns avaiable.<br>
&lt;fantasai> s/???/Ethan/<br>
&lt;fantasai> s/???/Ethan/<br>
&lt;oriol> q+<br>
&lt;TabAtkins> iank_: With the current masonry spec, this makes it... when you place masonry items, they can span variable # of tracks for sizing, that's a somewhat complex interaction<br>
&lt;TabAtkins> fantasai: I think for sizing they'd span the min<br>
&lt;TabAtkins> miriam: I'd also assume that<br>
&lt;TabAtkins> iank_: I don't know if that's correct<br>
&lt;TabAtkins> fantasai: It's a bit awkward for masonry in general. even if you're doing placement, because of the way masonry works you want to palce it into the shortest column, but then you won't bea ble to span anyway<br>
&lt;TabAtkins> fantasai: Some cases where you can, but it's rare - you need similar-height items lining up in rows, and then you probably dont' need masonry anyway<br>
&lt;TabAtkins> iank_: Yeah, for final palcement. But for track sizing, if you're running "place everywhere in ever position", you can have something that'll span 10, then 9, then 8, etc<br>
&lt;TabAtkins> fantasai: That's why when you're calculating sizes, assume it's spanning the min<br>
&lt;TabAtkins> fantasai: Since it'll usually not span more than that<br>
&lt;TabAtkins> Rossen__: we're out of time, let's continue discussing in the issue<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5852#issuecomment-2048058978 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 10 April 2024 17:02:03 UTC