Re: [csswg-drafts] [css-grid][css-contain] Clarify that `contain:size` affects track sizing (#4931)

The [definition of intrinsic sizes](https://drafts.csswg.org/css-sizing-3/#intrinsic-size) is explicitly about the min-content size and max-content size, not about track sizes or any other sizable aspect of an box (grid track sizes, multicol column sizes, etc). So by my reading (and by my intent when writing it), the spec calls for finding out the min-content width and height and max-content width and height (if you ever need them) and the width and height of the element as if it were empty, and once you've done that, you do full layout using these sizes. Yes, it does imply that you run the grid track sizing algorithm twice, once with empty tracks (for sizing purposes) and once with actual content (when doing the layout). A possible implementation strategy could be to have a specialized (and simpler/faster) implementation of the track sizing algo that only does track-sizing of an empty grid.

I'm still not understanding how the spec can be seen as ambiguous about that. For example, you said:
> In fact, a strict reading of the spec implies that it shouldn't occur: "When calculating the size of the containing box, including when computing its intrinsic size, it must be treated as having no contents."
> 
> The "treated as having no contents" implies that implicit tracks should not be created (since there are no items if we treat it as having no contents)

However, to get to this interpretation, you need to ignore the "when calculating …" part of the sentence. *When you calculate the size of the box*, you treat it as having no content, and therefore do not reserve room for any implicit track. *When laying out the grid into that size*, you do the full grid layout, with its content, including sizing the tracks correctly, and creating implicit tracks as necessary.

Even if it is not ambiguous, it may still be a bad idea. I don't think it is a bad idea, but we can discuss that.

* The advantage of switching to "option A" would be that we would only need to size the tracks once, rather than twice. Even with specialized first pass that can only handle empty grids but works faster on those, doing things once is should always be faster than doing them twice.

* The disadvantage of doing "option A"  is that it makes the feature less useful: gird sizes its track the way it does because that's the most useful thing to do for the layout of the grid. While contain:size defines what happens to auto-sized elements, it's largely meant to be used on elements that have a fixed author-supplied size. And regardless of how we end up getting the size we ant to layout into, within that size, calculating the track sizes normally will result in a normal grid layout. Calculating track sizes as if the grid were empty and laying out the grid items within those will result in a worse layout, and that difference is not necessary to realize the benefits expected from size containment.


Anyway, If I understand correctly, you're not necessarily advocating for "option A", merely saying that the spec could be read that way, and want it to be clearer on whether it means A or B.

I remain unconvinced that it can be read to mean option A, but nonetheless, if you have a suggestion of better phrasing to gets unambiguously to option B, it's always better to be clearer.

By the way, the reason why the grid text is in a note is that no additional normative requirement is meant on grid, and this is just an illustration/reminder of how the preceding normative text is meant to be applied to grid. I believe that option A would be special rules for grid, and would need to be normative.

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4931#issuecomment-612731894 using your GitHub account

Received on Monday, 13 April 2020 03:24:41 UTC