[csswg-drafts] how should inline-axis intrinsic sizing work for 'fit-content' and 'fit-content()'? (#3731)

dbaron has just created a new issue for https://github.com/w3c/csswg-drafts:

== how should inline-axis intrinsic sizing work for 'fit-content' and 'fit-content()'? ==
This issue is probably blocking implementation of the `fit-content()` function (which is in css-sizing-3) in Gecko, based on [a bug comment](https://bugzilla.mozilla.org/show_bug.cgi?id=1312588#c9) I wrote a few months ago.  I realize I never filed an issue here about it, though, so I'm doing so now.

The css-sizing-4 spec's [definition of intrinsic sizes](https://drafts.csswg.org/css-sizing-4/#block-intrinsic) doesn't say how intrinsic sizing should treat the `fit-content()` function.  It also defines a behavior for the `fit-content` keyword that I'm not convinced makes sense.

What I wrote in the above bugzilla comment about how I think things ought to behave was the following:

> Intrinsic sizing behavior for this function (and for 'min-content', 'max-content', and 'fit-content' keywords) in the block dimension is not particularly relevant here, since they're all treated as the initial values.  while intrinsic sizing in the block dimension isn't particularly well defined until after https://github.com/w3c/csswg-drafts/issues/2890 happens, we don't need to worry about that here.
>
> I think the intrinsic sizing behavior for 'min-content' and 'max-content' in the inline dimension is pretty easy; they compute to a single length, and the intrinsic sizing behavior should be the same as for <length> type values (for whichever of 'inline-size', 'min-inline-size', or 'max-inline-size' is the case -- <length> values have different effects on the three of them).
>
> Intrinsic sizing for 'fit-content(<length>)' is also easy, since it also computes to a single length.
>
> However, intrinsic sizing for 'fit-content(<percentage>)' is harder, since what it resolves to in the end (during layout) depends on things *outside* the box.  All the previous cases were easy because the size specified is a function only of the contents of the element and the properties on it, but now we need to consider what to do for percentages.  Some of this may depend on how we treat inline-size: <percentage>, min-inline-size: <percentage>, and max-inline-size: <percentage>.  However, there are also cases where the way we treat those was a compromise that we made for compatibility, and we might want to do something better here.  (On the flip side, doing something different might also be confusing if developers are accustomed to the current behavior.)  In the past, there have been two ways to approach handling <percentage> in intrinsic widths:
>  (1) treat them just like 'auto' (i.e., pretend they're not there) -- this way has basically one at this point
>  (2) reverse-compute them on their own, where a box with max-content size S and width: P (a percentage, expressed so 1.0 is 100%) has a max-content contribution to its parent of S/P.  This prevents overlap in block-like layout, but isn't sufficient when there's more than one thing per line.
>  (3) reverse-compute them together, so that if a line/row/table-row has boxes with sizes S1...SN and percentages P1...PN and then other non-percentage (fixed) sized boxes F1...FN, the contribution of the entire row to its parent is the larger of sum(F1...FN)/(1 - max(sum(P1...PN), 1.0)) and any of Si/Pi.  The first term ensures that the sizes for the non-percentage parts fit within the percentage remaining after all the percentage parts, and the remaining terms ensure that each percentage part is big enough.  This is roughly what we do for tables.
>
> So (1) is simple for percentages -- but it's not immediately clear to me how it works for 'fit-content(<percentage>)'.  That's the part that I'd need to think about more.  Doing (2) or (3) is probably even more complicated.  But there's probably a simpler way to think about what's needed for fit-content() that I haven't quite thought of yet...
>
> Intrinsic sizing for the 'fit-content' keyword is, I think, basically the same as 'fit-content(<percentage>)', except that it has to deal with padding/border/margin differently.  But there's also a little less justification for it to behave like <percentage> does today.

So, in other words, I think it's easy to specify the inline-axis intrinsic size behavior for `fit-content(<length>)` although the spec doesn't do so today.  It would just need to be added to the [clause](https://drafts.csswg.org/css-sizing-4/#block-intrinsic) that now says:

> If the computed inline-size of a block-level box is min-content, max-content, or a definite size ...

I think it's harder to specify the behavior for `fit-content(<percentage>)` (which the spec doesn't specify today) or for `fit-content` (which the spec currently says is the same as `auto` or `stretch`... but it's not clear to me that that's a good behavior).

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3731 using your GitHub account

Received on Wednesday, 13 March 2019 22:17:12 UTC