Re: [csswg-drafts] [css-grid-3] intrinsic track sizing algorithm for masonry can go exponential in complexity. (#10053)

The CSS Working Group just discussed `[css-grid-3] intrinsic track sizing algorithm for masonry can go exponential in complexity.`, and agreed to the following:

* `RESOLVED: allowing mixed track sizing,  as long as the algorithm does not allow position-dependent effects`
* `RESOLVED: add a note about the grouping optimization and baseline handling`

<details><summary>The full IRC log of that discussion</summary>
&lt;noamr> fantasai: TabAtkins, Iank_ and I discussed this on monday, and decided that we think this is doable, want to resolve that we allow mixed track sizing on masonry and investigate<br>
&lt;noamr> fantasai: it is currently a point of contention<br>
&lt;fantasai> Proposed resolution? Allow mixed track sizing in masonry; investigate applying limitations on the size contributions of subgrid/submasonry child items to avoid pathological performance characteristics.<br>
&lt;noamr> IanK_: it would be good to explicitly spec how you're supposed to group things and then apply the sizing algo, otherwise it would get lost and implementers won't do it correctly<br>
&lt;noamr> IanK_: we need to list out how you're supposed to do this, and also mention the positional independence thing<br>
&lt;noamr> IanK_: to get the perf characteristics, you have to group everything by how it's sized, and then apply the track sizing algorithm<br>
&lt;noamr> IanK_: it's different from today where all the items are having applied the track sizing algorithm together<br>
&lt;noamr> fantasai: it's an optimization of the currently spec'ed algo, we can add it as a note for a possible optimization<br>
&lt;noamr> fantasai: I want to keep the algo easy to read<br>
&lt;noamr> IanK_: for an implementor, if they have to dig notes to find important optimizations it's difficult<br>
&lt;noamr> fantasai: there are further optimizations, this is not the only possible optimizations<br>
&lt;noamr> fantasai: It's ok to outline this, but it's not our jobs in specs to detail exactly how to optimize stuff. we might not come to the right solution. This problem exists in all spec<br>
&lt;noamr> fantasai: translating spec directly into code is a bad habit<br>
&lt;TabAtkins> It is useful to give guidance when something should be done in a particular way, fwiw.<br>
&lt;fantasai> Yeah, I'm fine with giving guidance<br>
&lt;noamr> IanK_: I don't want to lose the positional idenependence stuff as it requires for the algorithm to work<br>
&lt;TabAtkins> If there *is* a behavioral difference, tho, then it does matter and needs to be in teh algo, obvs.<br>
&lt;fantasai> obvs<br>
&lt;noamr> IanK_: positional independence is key to get this opt to work<br>
&lt;noamr> IanK_: otherwise we're back to CSS2.1 where there are no algorithm specified<br>
&lt;noamr> IanK_: we can write the basic constraints and build the other constraints on top of that<br>
&lt;noamr> astearns: hearing a few things to resolve. is this merely an optimization?<br>
&lt;noamr> fantasai: yes<br>
&lt;noamr> IanK_: as long as we have positional independence<br>
&lt;noamr> IanK_: the current algorithm does have positional dependence<br>
&lt;noamr> astearns: is the first resolution that we allow mixed track size, with a normative bit on positional independence<br>
&lt;noamr> proposed resolution: allow mixed track sizing on masonry, as long as the algorithm does not allow position-dependent effects<br>
&lt;noamr> RESOLVED: allowing mixed track sizing,  as long as the algorithm does not allow position-dependent effects<br>
&lt;noamr> astearns: proposed resolution, add a note about the grouping optimization and baseline handling<br>
&lt;noamr> RESOLVED: add a note about the grouping optimization and baseline handling<br>
&lt;noamr> fantasai: investigate limitations on subgrid contribution of subgrid items to avoid perf issues<br>
&lt;noamr> fantasai: we need to dig more<br>
&lt;noamr> astearns: any other resolutions needed on this one?<br>
&lt;TabAtkins> ScribeNick: TabAtkins<br>
</details>


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


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

Received on Wednesday, 31 July 2024 16:48:11 UTC