[css-grid] What track sizes match the concept of "intrinsically-sized track" ?

[javifernandez]

The inline-axis and block-axis alignment sections have the following statement:

https://drafts.csswg.org/css-grid/#row-align

If baseline alignment is specified on a grid item whose size in that axis depends on the size of an intrinsically-sized track (whose size is therefore dependent on both the item’s size and baseline alignment, creating a cyclic dependency), that item does not participate in baseline alignment, and instead uses its fallback alignment.

I'm not sure whether some possible values of the track sizing functions may or not produce an intrinsically-sized track. So, I'll collect some cases here that I think they match and other I'd have doubts;

1. auto -> minmax(auto, auto): yes
2. min-content -> minmax(min-content, max-content): yes
3. fit-content -> minmax(auto, fit-content): yes
4. max-content -> minmax(max-content, max-content): yes
5. 1fr -> minmax(auto, 1fr): ??
6. minmax(auto, 20px): yes
7. minmax(20x, auto): yes
8. minmax(min-content, 20px): yes
9. minmax(20px, min-content): yes
10. minmax(20px, 1fr): ??

Basically, in the Chrome and Webkit implementation we are considering that any content-sized track (I'll fill a new issue about this term too) will produce intrinsically-sized tracks. Additionally, we consider a track as content-sized if either its min-sizing function or its max-sizing function is a content-sized value (auto, min-content or max-content).

Finally, my doubts regarding the flex tracks are related to their dependency with the available size, which will come from the grid container's inline and block size. We assume in both, Chrome and WebKit that a flex track in a indefinite sized container should be considered as content-sized. I couldn't find in the spec where this is specified; maybe we should if it's not the case. I'll file a new issue about this if it's worth discussing it.

I've got more questions, which may be related with this one. However, I'll fill separate issues for now; we can merge then if we think all of them are part of the same issue.

[fantasai]

Wrt examples, 5=yes, 10=no.

[javifernandez]

What about case 10 in a grid with indefinite size ? Shouldn't we consider this track as intrinsically sized according to the following statement ?

https://drafts.csswg.org/css-grid/#fr-unit

When the available space is infinite (which happens when the grid container’s width or height is indefinite), flex-sized grid tracks are sized to their contents while retaining their respective proportions.

[tabatkins]

Reviewing the spec, it looks like we didn't consider the interaction of baseline alignment and fr values in indefinitely-sized containers. I think Chrome/WebKit's current behavior, of treating such tracks as intrinsically-sized and thus triggering fallback alignment for extrinsically-sized baseline-aligned items, is reasonable.

We should clarify the spec on this point, and also how baseline alignment is applied in fr tracks with indefinite free space.

[fantasai]

Agenda+ for review. (I don't think this is controversial, but it is a substantive change.)

[css-meeting-bot]

The CSS Working Group just discussed What track sizes match the concept of "intrinsically-sized track" ?, and agreed to the following:

• RESOLVED: Accept the edits.

The full IRC log of that discussion

<heycam> Topic: What track sizes match the concept of "intrinsically-sized track" ?
<heycam> github: https://github.com//issues/3042
<heycam> Rossen: fantasai can you summarize?
<Rossen> github: https://github.com//issues/3042
<heycam> fantasai: just made some changes and wanted to check that nobody had any issue with the changes
<heycam> ... wedefined flexible tracks as intrinsically sized when the grid container has an indefinite size in that axis
<fantasai> https://github.com/w3c/csswg-drafts/commit/b86cf52f9d5dca765efa8758896a989847a5c68c
<heycam> ... the reason we did that is when you're sizing under a max-content constraint, and you have flexible tracks, we do consider the size of the grid when determining that isze
<heycam> ... if the grid floated, with 2 fr tracks -- normally with a fixed size of the grid each track will be 1fr
<heycam> ... minmax(0, 1fr)
<heycam> ... but if you are max-content sized, you will look at the content
<heycam> ... maybe something in one track tacks up 100px, the other track even if empty will be 100px
<heycam> ... since we're trying to size the grid such that each track is at least the size of its max-content and it's equially distributed
<heycam> ... here they are considered instrinsically sized
<heycam> ... so that means when your'e doing baseline alginment stuff, there are cyclic dependenies
<heycam> ... and we cut the loop by ignoring certain baseline alignments
<heycam> ... which is what originally brought up the issue
<heycam> ... so I wanted to double check this all seems ok
<heycam> Rossen: the change seems ok on our side
<heycam> ... in fact I was almost surprised we're adding this so late
<heycam> ... reading through the explanation is exactly what I'd expect the distribution algorithm to do
<heycam> ... so adding this clarification is good, we're in support
<heycam> ... any other feedback?
<heycam> ??: I was fine wiht this change
<heycam> ... we wondered if it will be necessary to add something to clarify that this flexible tracks will be considered intrinsically sized even after having resolved the container size in subsequent passes of the grid sizing alg
<heycam> ... I mentioned that since Mats already requested something similar for the percentage track resolution
<heycam> ... where the grid container is intiially undefined, and after being determined the intrinsic size, we use that size to resolve the percetnage tracks
<heycam> ... we wonder if in this case we need to clarify that these flexible tracks will be considered intrinsic even though we already resolved the intrinsic size
<heycam> ... because of baseline alignment it has an important impact
<heycam> ... we decide to discard some items from baseline alignment because of this cyclyic dependency
<heycam> ... once you resolve intrinsic size, it's the agreement we should ....
<heycam> ... these flexible tracks should still be considered intrinsically sized
<heycam> ... there is no min-content constraint
<fantasai> https://github.com//issues/3046
<heycam> fantasai: I think you raised a similar issue here in 3046
<heycam> ... we can try to clarify if you point out what is needed
<lajava> https://github.com//issues/1921#issuecomment-399170288
<heycam> ... if the track is considered intrinsically sized then the determination is constant
<heycam> lajava: Mats also reequested a similar thing for percentage tracks
<heycam> fantasai: I don't know if it makes sense as much, would have to think about it
<heycam> Rossen: percetnage tracks in the context of resolving tracks during measuring?
<heycam> lajava: yes
<heycam> s/??/lajava/
<heycam> Rossen: we have discussed this at the past, and our agreement AFAIR is that percentages in this case are ignored
<heycam> ... and the intrinsic size is used
<heycam> lajava: then we use the resolved intrnsic size to again resolve the percentage tracks?
<heycam> ... but we are not doing the same with flexible tracks
<heycam> ... we consider them intrinsically sized even though the grid container is not indefinite any more
<heycam> ... so we are not doing the same in both cases
<heycam> Rossen: they are not, because the percentage will resolve during the layout pass
<heycam> ... and for the fr the expectation is that you would have the max-content contribution size taken by that track
<heycam> ... if the track were 50% instead of 1fr, you would get 50% of what the max contribution would end up
<heycam> ... they are the same during hte measuring pass, intrinscis sizing, but don't beahve the same during the layout sizing
<heycam> ... so I'm not sure we need to be necesssarily talking about the two as being the same thing
<heycam> lajava: I understand
<heycam> ... I wonder if we should specify for the case of the flexible tracks if in this case second pass, in case of orthogonal items were you have to repeat the sizing alg, that we should still keep the original behavior of these fleixble tracks being instrincially sized
<heycam> ... and ignore the already resolved value
<heycam> ... it may be enough with the current spec
<heycam> lajava: the change says that for this prupose flex tracks count as intrinsically sized when the grid container has an indefinite size in the relevant axis
<heycam> Rossen: the relevant axis is the key
<heycam> ... just trying to process your assertion about orthogonal content and if that has any bearing on this
<heycam> lajava: when you repeat the track sizing alg as the spec says, for the case of orthogonal items, in this second pass is it still true that the grid container has indefinite size?
<heycam> Rossen: it should
<heycam> lajava: yes, I think that is what fantasai and Tab resolved in another issue
<heycam> ... but should we specify that somehow?
<heycam> ... or is it obvious
<heycam> fantasai: I don't know where I would clarify it, but if someone suggests I'm happy to
<fantasai> Here's the spec
<fantasai> https://drafts.csswg.org/css-grid-1/#row-align
<heycam> Rossen: how about lajava if you have the time I would suggest handling this as part of the other issue that was pointed about by fantasai
<heycam> ... 3046
<heycam> lajava: ok
<fantasai> "If baseline alignment is specified on a grid item whose size in that axis depends on the size of an intrinsically-sized track (whose size is therefore dependent on both the item’s size and baseline alignment, creating a cyclic dependency), that item does not participate in baseline alignment, and instead uses its fallback alignment as if that were originally specified. For this purpose, <flex> track
<fantasai> sizes count as “intrinsically-sized” when the grid container has an indefinite size in the relevant axis.
<heycam> Rossen: and then we can decide whether or not we need to change anything
<fantasai> Note: Whether the fallback alignment is used or not does not change over the course of layout: if a cycle exists, it exists."
<heycam> fantasai: [reads above quote]
<heycam> lajava: ok
<heycam> Rossen: back to the original issue, any additional comments about the edits?
<heycam> ... any objections on accepting the edits for issue 3042?
<heycam> [none heard]
<heycam> RESOLVED: Accept the edits.

[javifernandez]

I've added a few tests to cover this issue, and specially issue #3046. See bellow and maybe add feedback about their correctness or whether we would need more. Otherwise, I guess can can remove the Need Testcase label.

I'm still implementing the new behavior, as resolved in issue #3046, which will change a few cases of these tests, though.

• grid-self-baseline-not-applied-if-sizing-cyclic-dependency-001.htm
• grid-self-baseline-not-applied-if-sizing-cyclic-dependency-002.htm
• grid-self-baseline-not-applied-if-sizing-cyclic-dependency-003.htm