[css-grid] Intrinsic size of grid containers · Issue #2303 · w3c/csswg-drafts (original) (raw)

The spec text is very clear about this and has been around for a long time:

The max-content size (min-content size) of a grid container
is the sum of the grid container's track sizes (including gutters)
in the appropriate axis, when the grid is sized
under a max-content constraint (min-content constraint).

But it seems not all the browsers are doing it, or at least not all
are doing it properly.

Firefox is following the spec, and it runs the track sizing algorithm twice
(one under min-content constraint and another under max-content constraint)
to compute the min|max-content widths of the grid container.

However Blink and WebKit follow a different approach.
In this case they just run the track sizing algorithm once
with an available space of zero and use the sum of base sizes
as min-content size and the sum of the growth limits as max-content size.
The reason why these browsers do it that way is because
this was suggested back in 2013 by Julien Chaffraix in www-style
and never modified later.

Regarding Edge I don't know what's their implementation, but I'm finding
the same issues than in Blink and WebKit. So I guess Edge is either
not following the spec or not implementing it properly.

Let's go to the examples and why I'm bringing up this issue.

The key part of the track sizing algorithm that is affected by this
is when we resolve intrinsic track sizes
(for both non-spanning and spanning items we have a similar text):

Imagine the following example:

Lorem ipsum.

The intrinsic sizes should be:

As the grid container is inline-grid, its sized as fit-content:
min(max-content size, max(min-content size, stretch-fit size)).
In this example, min(100px, max(50px, 20px)) = 50px.

Note: This also matches what happens in a similar case using inline-block instead of inline-grid.

Output in Firefox vs other browsers of the previous example

In Blink and WebKit we always go through the Otherwise paragraph,
so the min-content size is 0px and the final width is 20px.
The same result happens on Edge, though I don't know how is that implemented.
In any case it seems quite clear that this is a bug in Blink, WebKit and Edge
and their behavior should be modified.

Note that to fix this, we'll need to follow a similar approach than Firefox,
which means that the track sizing algorithm will be run 3 times:

This is not all, now let's go to a different example:

Lorem ipsum.

To calculate the min-content size, all the browsers seem to apply the clamping
described in Automatic Minimum Size of Grid Items section
of the spec. So the min-content size is 0px.
However to calculate the max-content size, Firefox uses
the max-content contribution as requested by the spec, that's 100px.
This makes that the intrinsic size of the grid container is 100px.
However during layout the track sizing algorithm is run again,
and as during layout it doesn't know if it's under a min-content
or max-content constraint, it goes through the Otherwise sentence
and apply the clamping, so the track has 0px width.
This causes a weird effect as the track is 0px
but the grid container is 100px.

Output in Firefox vs other browsers of the previous example

In Blink and WebKit the result is better, the grid container is 0px
as we always go through the Otherwise sentence and apply the clamping.
Edge has the same output too.

In a Firefox bug
@MatsPalmgren suggests that we apply the automatic minimum size clamping
when we are under a min-content constraint, max-content constraint
or no constraint.
That would make Firefox has the same output than the other browsers
in this last example.

It'd be nice to get the feedback from @atanassov about this issue,
as we don't know how the intrinsic size is being calculated in Edge.

Check the following codepen to see the examples live and play with them:
https://codepen.io/mrego/pen/xYdvbZ