Re: [csswg-drafts] [css-grid] Inconsitence of the "intrinsically-sized track" concept when using flexible tracks

Let's focus now on the comment bellow, which I think it's the key point to clarify here.

> Then step 4 happens - the columns are fixed, rows are un-fixed (because we're calculating them again), and so the cyclic-check is made for the rows, and once again, the vertical item still depends on an intrinsically-sized track, so it still can't baseline-align.

The statement that I'm not sure about is this conclusion you made that the vertical _item depends on an intrinsically-sized track_. The track has a flex size and, as far as I understand, it's intrinsic nature depends on the definiteness of the available space (in this case, the grid container height). 

The grid area the item we are evaluating for a sizing-cycle is not intrinsically sized because the rows are "un-fixed" as you said. Even though we are resolving the row's size, if the grid container height was definite, the fr track would have been treated as fixed size, for the purpose of this sizing cycle check. 

This is the main doubt that I, and a few other devs at Igalia (we used several meetings to discuss about this and I admit we still haven't reach an agreement). Is the available space definite during the step 4 ? Can/Should assume that the rows' size determined in Step 2 can be used to set the grid container's height, hence it can/should we use it as definite available space for computing rows' size in Step 4 ? 

If "yes" is the answer of both questions, I guess that, according to the spec, we should treat the fr tacks as fixed size during this Step 4, hence, the vertical item would not be under a cyclic sizing dependency and it indeed would participate in baseline alignment.

Personally, I'd be more in favor of an interpretation like the one fantasai proposed, where this definite/indefinite condition is determined once for all at the beginning of the track sizing algorithm. However, this would require, in my opinion, a more complex editing. 

Maybe I'm wrong on some of my assumptions above, and we should treat the vertical item as not participating in baseline alignment even in the extra Step 4 of the track sizing algorithm; this is in my opinion what I'd would expect as rendering result. However, I'm afraid that with the current spec, we can't conclude that.

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

Received on Tuesday, 11 September 2018 21:25:02 UTC