[css-grid] Inconsitence of the "intrinsically-sized track" concept when using flexible tracks #3046
Comments
The new Baseline Alignment algorithm states that items with sizing cyclic dependencies must be excluded from any baseline context they participate in. One of these cyclic dependencies can happen with intrinsic sized grid areas and relative items. The grid spec states [1] that flex-sized tracks should be considered as content-sized when the grid container has an indefinite size. We were using the AvailableSize(direction) function to determine whether the grid container is indefinite or not. However, this function doesn't provide consistent results during the different phases of the grid layout logic. The new Baseline Alignment logic is now integrated in the Grid Track sizing algorithm. Hence, we need to ensure that an item that participates in any baseline alignment context during the track sizing also does during the alignment phase, at the end of the grid layout logic. However, the AvailableSize(direction) could indicate that the grid has an indefinite size during the track sizing, but it returns a definite size during alignment. This issue leads to inconsistencies regarding the participation of an item in baseline alignment, so it may raises the assertion of having a context, like it happens in the bugs this CL tries to fix. For inline-axis, we'll assume indefinite constraints only during intrinsic size computation; afterwards, we'll always assume definite size. This issue could imply that baseline shims are not considered to compute the grid's intrinsic size, but are then used to calculate the actual size of the grid tacks, which may lead to such tracks overflowing the grid container. In the case of block-axis sizing, we determine the indefinite or definite size constraints during layout. However, the presence of orthogonal grid items imply the execution of the 3rd step of the grid sizing, repeating the execution of track sizing algorithm in both directions. During this phase, we can't assume indefinite size constraints anymore because block-axis has been determined already in the previous 2 steps. While baseline shims computed in the previous steps shouldn't vary even if the tracks' size change during this phase, it's possible that items not participating in baseline alignment before may do participate in this phase. The inclusion of new items in the baseline context may indeed change the baseline shims, which will be used to determine the tracks' size during this step. This CL removes the early return that prevented he Baseline offsets to be computed again during the step 3. This change assumes the already mentioned inconsistencies, which I hope we can clarify in the issue [2] I filed for the CSS WG. [1] https://drafts.csswg.org/css-grid/#fr-unit [2] w3c/csswg-drafts#3046 Bug: 867833, 874861, 876593 Change-Id: I668d399b920c9280a8e20b3e8362f562eded4770
The new Baseline Alignment algorithm states that items with sizing cyclic dependencies must be excluded from any baseline context they participate in. One of these cyclic dependencies can happen with intrinsic sized grid areas and relative items. The grid spec states [1] that flex-sized tracks should be considered as content-sized when the grid container has an indefinite size. We were using the AvailableSize(direction) function to determine whether the grid container is indefinite or not. However, this function may provide different results during the different phases of the grid layout logic. This issue causes assert violations like the one described in the bugs listed below. The new Baseline Alignment logic is now integrated in the Grid Track sizing algorithm. Hence, we need to ensure that an item that participates in any baseline alignment context during the track sizing also does during the alignment phase, at the end of the grid layout logic. In order to achieve that, this CL forces a new computation of the Baseline offsets during the step 3 of the Grid sizing algorith, since during this step the available space is not indefinite anymore. It's worth mentioning that this change assumes the issue grid items being excluded and included of Baseline Context during the different phases of the Grid sizing algorithm, which I hope we can clarify in the issue [2] I filed for the CSS WG. [1] https://drafts.csswg.org/css-grid/#fr-unit [2] w3c/csswg-drafts#3046 Bug: 867833, 874861, 876593 Change-Id: I668d399b920c9280a8e20b3e8362f562eded4770
The new Baseline Alignment algorithm states that items with sizing cyclic dependencies must be excluded from any baseline context they participate in. One of these cyclic dependencies can happen with intrinsic sized grid areas and relative items. The grid spec states [1] that flex-sized tracks should be considered as content-sized when the grid container has an indefinite size. We were using the AvailableSize(direction) function to determine whether the grid container is indefinite or not. However, this function may provide different results during the different phases of the grid layout logic. This issue causes assert violations like the one described in the bugs listed below. The new Baseline Alignment logic is now integrated in the Grid Track sizing algorithm. Hence, we need to ensure that an item that participates in any baseline alignment context during the track sizing also does during the alignment phase, at the end of the grid layout logic. In order to achieve that, this CL forces a new computation of the Baseline offsets during the step 3 of the Grid sizing algorith, since during this step the available space is not indefinite anymore. It's worth mentioning that this change assumes the issue grid items being excluded and included of Baseline Context during the different phases of the Grid sizing algorithm, which I hope we can clarify in the issue [2] I filed for the CSS WG. [1] https://drafts.csswg.org/css-grid/#fr-unit [2] w3c/csswg-drafts#3046 Bug: 867833, 874861, 876593 Change-Id: I668d399b920c9280a8e20b3e8362f562eded4770 Reviewed-on: https://chromium-review.googlesource.com/1177757 Reviewed-by: Sergio Villar <svillar@igalia.com> Reviewed-by: Emil A Eklund <eae@chromium.org> Commit-Queue: Javier Fernandez <jfernandez@igalia.com> Cr-Commit-Position: refs/heads/master@{#587799}
The new Baseline Alignment algorithm states that items with sizing cyclic dependencies must be excluded from any baseline context they participate in. One of these cyclic dependencies can happen with intrinsic sized grid areas and relative items. The grid spec states [1] that flex-sized tracks should be considered as content-sized when the grid container has an indefinite size. We were using the AvailableSize(direction) function to determine whether the grid container is indefinite or not. However, this function may provide different results during the different phases of the grid layout logic. This issue causes assert violations like the one described in the bugs listed below. The new Baseline Alignment logic is now integrated in the Grid Track sizing algorithm. Hence, we need to ensure that an item that participates in any baseline alignment context during the track sizing also does during the alignment phase, at the end of the grid layout logic. In order to achieve that, this CL forces a new computation of the Baseline offsets during the step 3 of the Grid sizing algorith, since during this step the available space is not indefinite anymore. It's worth mentioning that this change assumes the issue grid items being excluded and included of Baseline Context during the different phases of the Grid sizing algorithm, which I hope we can clarify in the issue [2] I filed for the CSS WG. [1] https://drafts.csswg.org/css-grid/#fr-unit [2] w3c/csswg-drafts#3046 Bug: 867833, 874861, 876593 Change-Id: I668d399b920c9280a8e20b3e8362f562eded4770 Reviewed-on: https://chromium-review.googlesource.com/1177757 Reviewed-by: Sergio Villar <svillar@igalia.com> Reviewed-by: Emil A Eklund <eae@chromium.org> Commit-Queue: Javier Fernandez <jfernandez@igalia.com> Cr-Commit-Position: refs/heads/master@{#587799}
The new Baseline Alignment algorithm states that items with sizing cyclic dependencies must be excluded from any baseline context they participate in. One of these cyclic dependencies can happen with intrinsic sized grid areas and relative items. The grid spec states [1] that flex-sized tracks should be considered as content-sized when the grid container has an indefinite size. We were using the AvailableSize(direction) function to determine whether the grid container is indefinite or not. However, this function may provide different results during the different phases of the grid layout logic. This issue causes assert violations like the one described in the bugs listed below. The new Baseline Alignment logic is now integrated in the Grid Track sizing algorithm. Hence, we need to ensure that an item that participates in any baseline alignment context during the track sizing also does during the alignment phase, at the end of the grid layout logic. In order to achieve that, this CL forces a new computation of the Baseline offsets during the step 3 of the Grid sizing algorith, since during this step the available space is not indefinite anymore. It's worth mentioning that this change assumes the issue grid items being excluded and included of Baseline Context during the different phases of the Grid sizing algorithm, which I hope we can clarify in the issue [2] I filed for the CSS WG. [1] https://drafts.csswg.org/css-grid/#fr-unit [2] w3c/csswg-drafts#3046 Bug: 867833, 874861, 876593 Change-Id: I668d399b920c9280a8e20b3e8362f562eded4770 Reviewed-on: https://chromium-review.googlesource.com/1177757 Reviewed-by: Sergio Villar <svillar@igalia.com> Reviewed-by: Emil A Eklund <eae@chromium.org> Commit-Queue: Javier Fernandez <jfernandez@igalia.com> Cr-Commit-Position: refs/heads/master@{#587799}
…fsets during step 3, a=testonly Automatic update from web-platform-tests[css-grid] Compute again the baseline offsets during step 3 The new Baseline Alignment algorithm states that items with sizing cyclic dependencies must be excluded from any baseline context they participate in. One of these cyclic dependencies can happen with intrinsic sized grid areas and relative items. The grid spec states [1] that flex-sized tracks should be considered as content-sized when the grid container has an indefinite size. We were using the AvailableSize(direction) function to determine whether the grid container is indefinite or not. However, this function may provide different results during the different phases of the grid layout logic. This issue causes assert violations like the one described in the bugs listed below. The new Baseline Alignment logic is now integrated in the Grid Track sizing algorithm. Hence, we need to ensure that an item that participates in any baseline alignment context during the track sizing also does during the alignment phase, at the end of the grid layout logic. In order to achieve that, this CL forces a new computation of the Baseline offsets during the step 3 of the Grid sizing algorith, since during this step the available space is not indefinite anymore. It's worth mentioning that this change assumes the issue grid items being excluded and included of Baseline Context during the different phases of the Grid sizing algorithm, which I hope we can clarify in the issue [2] I filed for the CSS WG. [1] https://drafts.csswg.org/css-grid/#fr-unit [2] w3c/csswg-drafts#3046 Bug: 867833, 874861, 876593 Change-Id: I668d399b920c9280a8e20b3e8362f562eded4770 Reviewed-on: https://chromium-review.googlesource.com/1177757 Reviewed-by: Sergio Villar <svillar@igalia.com> Reviewed-by: Emil A Eklund <eae@chromium.org> Commit-Queue: Javier Fernandez <jfernandez@igalia.com> Cr-Commit-Position: refs/heads/master@{#587799} -- wpt-commits: 16e4b911814b15f308f39cb06e5ac8b790608d37 wpt-pr: 12529
…fsets during step 3, a=testonly Automatic update from web-platform-tests[css-grid] Compute again the baseline offsets during step 3 The new Baseline Alignment algorithm states that items with sizing cyclic dependencies must be excluded from any baseline context they participate in. One of these cyclic dependencies can happen with intrinsic sized grid areas and relative items. The grid spec states [1] that flex-sized tracks should be considered as content-sized when the grid container has an indefinite size. We were using the AvailableSize(direction) function to determine whether the grid container is indefinite or not. However, this function may provide different results during the different phases of the grid layout logic. This issue causes assert violations like the one described in the bugs listed below. The new Baseline Alignment logic is now integrated in the Grid Track sizing algorithm. Hence, we need to ensure that an item that participates in any baseline alignment context during the track sizing also does during the alignment phase, at the end of the grid layout logic. In order to achieve that, this CL forces a new computation of the Baseline offsets during the step 3 of the Grid sizing algorith, since during this step the available space is not indefinite anymore. It's worth mentioning that this change assumes the issue grid items being excluded and included of Baseline Context during the different phases of the Grid sizing algorithm, which I hope we can clarify in the issue [2] I filed for the CSS WG. [1] https://drafts.csswg.org/css-grid/#fr-unit [2] w3c/csswg-drafts#3046 Bug: 867833, 874861, 876593 Change-Id: I668d399b920c9280a8e20b3e8362f562eded4770 Reviewed-on: https://chromium-review.googlesource.com/1177757 Reviewed-by: Sergio Villar <svillar@igalia.com> Reviewed-by: Emil A Eklund <eae@chromium.org> Commit-Queue: Javier Fernandez <jfernandez@igalia.com> Cr-Commit-Position: refs/heads/master@{#587799} -- wpt-commits: 16e4b911814b15f308f39cb06e5ac8b790608d37 wpt-pr: 12529
|
I think the point of confusion is that you're evaluating whether the item is in a cyclic layout situation within the scope of a particular step in the algorithm. Within such a narrow scope, you get different answers depending on which step you're in. But the decision of whether an item can be baseline-aligned or not due to cyclic dependencies is at the top level. If any part of the layout creates this cycle, the cycle exists, and you must use fallback alignment--and that fallback alignment applies as if it were originally specified, not only in certain steps. |
|
This implication, however (that the cyclic-baseline check is performed once at the beginning of track layout, and persists thru the later steps where the track may be treated as fixed) is not clear from the language, so we need to fix it. ^_^ |
|
(@fantasai and I are arguing with each other over these comments even tho we're sitting next to each other irl.) |
|
It's clear because it's unconditional and unscoped. It's defined at the same level as "if you're in a vertical writing mode, an 'auto' dominant baseline is treated as 'center' and in a horizontal writing mode it is treated as 'alphabetic'. We could make it clearer by being extra explicit about this, but the only condition is “there is a cycle during layout” and the command is ”treat baseline as its fallback”, with no conditions or scoping or timing constraints. |
|
By definition it's not clear, since Javi didn't understand it, and I would have interpreted it differently five minutes ago too. ^_^ |
|
To be a bit more explicit: Figuring out the baseline-alignment shims is a part of the track sizing algorithm, and this is run for one set of tracks at a time, either the rows or the columns. In this case, step 2 figures out row heights, and assigns block-axis margins to baseline-align between rows. (Which, due to the vertical item not participating, means that everyone gets 0-sized shims; they're not baseline-aligning.) Then step 3 happens - we treat the row as fixed-size, but we're working on the columns. So the baseline-shim determination is for the columns - we're adding inline-axis margins to align things across a column. The fact that the row is fixed has no relevance here; the cyclic check we're doing is for widths (and in this case, the column widths are both fixed at 100px, so everything's cool). 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. |
It does say when to calculate these - it's done in step 11.5.1. That's part of the Track Sizing Algorithm, tho (and does get re-run in step 3/4), so it looks like it's consistent with what you're already doing. ^_^ |
…ring out available space). Also wordsmith. #3046.
I guess with 11.5.1 you meant the Step 1 in the 11.5 section: https://drafts.csswg.org/css-grid/#algo-baseline-shims Then, yes, we assume that but I meant that it was not explicitly stated. I didn't want to imply that the text would need edits to clarify it, though, just that we assumed it was necessary to do it in that precise step. Then, we are on the same page regarding this specific sub-topic of the issue, about when to compute the baseline shims. I'm happy because it's a very important point of this issue. |
|
Let's focus now on the comment bellow, which I think it's the key point to clarify here.
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. |
Regarding this we're currently assuming in Chromium and WebKit that grid size (width and height) is definite when we repeat the track sizing algorithm (steps 3 and 4).
About the particular problem of this issue, I agree with @fantasai that we should determine this at the beginning and then don't change the status during the whole track sizing algorithm. |
No. Step 4 tells you what information to use - it mentions using the column widths you calculated in step 3, but makes no mention of the previous attempt at row heights from step 2. So you ignore everything that happened in step 2; it has no relevance during step 4.
Are there any particular edits you need for this to be clearer? |
|
With the edits from #3042 it seems we won't need changes:
We guess that has an indefinite size is true on the first pass and also on the second pass. Note that in order to resolve percentages rows on a grid container with indefinite size, we are setting the intrinsic height after the first pass and then use that size to resolve the percentages in the second pass. For that reason @MatsPalmgren asked for some extra changes on the spec in this comment:
If we do that maybe we'd need some extra clarification on the "intrinsically-sized" and flex tracks sentence. As otherwise both texts would be somehow contradictory: in one place we would say that after the first pass the height is definite, then with the current sentence the flex track would be "intrinsically-sized" on the first pass but not on the second pass. |
The CSS WG resolved [1] that we should determine the existence of cyclic sizing dependencies at the begining of layout, and this condition must be kept during the next phases of the grid layout algorithm. This has some interesting implications for Baseline Alignment, since we must exclude from participating in Baseline Alignment those items that have a cyclic sizing dependency with the grid area they are located into. We were using the AvailableSpace() function to determine when a grid area may be defined under indefinite sizing constraints, which would make tracks with a flex max-sizing function to behave like an intrinsically sized track. However, the result of this function may be different during the different steps of the grid layout algorithm. The consequences of this undetermined results may cause that items excluded from participating in Baseline Alignment during the grid's intrinsic size computation, or even in the first steps of the layout (orthogonal items may force an extra cycle of the layout algorithm), could be selected to participate later in the next steps. The CSS WG clarified that once we detect a cyclic sizing dependency the affected items must be definitively excluded from participating in Baseline Alignment. In order to implement this new behavior, this patch provides a deterministic way to know whether the grid container is sized under indefinite constraints. [1] w3c/csswg-drafts#3046 Bug: 941987 Change-Id: I9b2ae86af9c675bf59dff639dfcbb362c2f302ba
|
I'm currently implementing the agreed new behavior in chrome (I'll do the same for Safari as soon as possible), so I think we can close this issue, unless @rego or anybody else has anything to add. |
…fsets during step 3, a=testonly Automatic update from web-platform-tests[css-grid] Compute again the baseline offsets during step 3 The new Baseline Alignment algorithm states that items with sizing cyclic dependencies must be excluded from any baseline context they participate in. One of these cyclic dependencies can happen with intrinsic sized grid areas and relative items. The grid spec states [1] that flex-sized tracks should be considered as content-sized when the grid container has an indefinite size. We were using the AvailableSize(direction) function to determine whether the grid container is indefinite or not. However, this function may provide different results during the different phases of the grid layout logic. This issue causes assert violations like the one described in the bugs listed below. The new Baseline Alignment logic is now integrated in the Grid Track sizing algorithm. Hence, we need to ensure that an item that participates in any baseline alignment context during the track sizing also does during the alignment phase, at the end of the grid layout logic. In order to achieve that, this CL forces a new computation of the Baseline offsets during the step 3 of the Grid sizing algorith, since during this step the available space is not indefinite anymore. It's worth mentioning that this change assumes the issue grid items being excluded and included of Baseline Context during the different phases of the Grid sizing algorithm, which I hope we can clarify in the issue [2] I filed for the CSS WG. [1] https://drafts.csswg.org/css-grid/#fr-unit [2] w3c/csswg-drafts#3046 Bug: 867833, 874861, 876593 Change-Id: I668d399b920c9280a8e20b3e8362f562eded4770 Reviewed-on: https://chromium-review.googlesource.com/1177757 Reviewed-by: Sergio Villar <svillarigalia.com> Reviewed-by: Emil A Eklund <eaechromium.org> Commit-Queue: Javier Fernandez <jfernandezigalia.com> Cr-Commit-Position: refs/heads/master{#587799} -- wpt-commits: 16e4b911814b15f308f39cb06e5ac8b790608d37 wpt-pr: 12529 UltraBlame original commit: 7a1e05b09e40b019b67ba54e64e983fcd8b30d0e
…fsets during step 3, a=testonly Automatic update from web-platform-tests[css-grid] Compute again the baseline offsets during step 3 The new Baseline Alignment algorithm states that items with sizing cyclic dependencies must be excluded from any baseline context they participate in. One of these cyclic dependencies can happen with intrinsic sized grid areas and relative items. The grid spec states [1] that flex-sized tracks should be considered as content-sized when the grid container has an indefinite size. We were using the AvailableSize(direction) function to determine whether the grid container is indefinite or not. However, this function may provide different results during the different phases of the grid layout logic. This issue causes assert violations like the one described in the bugs listed below. The new Baseline Alignment logic is now integrated in the Grid Track sizing algorithm. Hence, we need to ensure that an item that participates in any baseline alignment context during the track sizing also does during the alignment phase, at the end of the grid layout logic. In order to achieve that, this CL forces a new computation of the Baseline offsets during the step 3 of the Grid sizing algorith, since during this step the available space is not indefinite anymore. It's worth mentioning that this change assumes the issue grid items being excluded and included of Baseline Context during the different phases of the Grid sizing algorithm, which I hope we can clarify in the issue [2] I filed for the CSS WG. [1] https://drafts.csswg.org/css-grid/#fr-unit [2] w3c/csswg-drafts#3046 Bug: 867833, 874861, 876593 Change-Id: I668d399b920c9280a8e20b3e8362f562eded4770 Reviewed-on: https://chromium-review.googlesource.com/1177757 Reviewed-by: Sergio Villar <svillarigalia.com> Reviewed-by: Emil A Eklund <eaechromium.org> Commit-Queue: Javier Fernandez <jfernandezigalia.com> Cr-Commit-Position: refs/heads/master{#587799} -- wpt-commits: 16e4b911814b15f308f39cb06e5ac8b790608d37 wpt-pr: 12529 UltraBlame original commit: 7a1e05b09e40b019b67ba54e64e983fcd8b30d0e
…fsets during step 3, a=testonly Automatic update from web-platform-tests[css-grid] Compute again the baseline offsets during step 3 The new Baseline Alignment algorithm states that items with sizing cyclic dependencies must be excluded from any baseline context they participate in. One of these cyclic dependencies can happen with intrinsic sized grid areas and relative items. The grid spec states [1] that flex-sized tracks should be considered as content-sized when the grid container has an indefinite size. We were using the AvailableSize(direction) function to determine whether the grid container is indefinite or not. However, this function may provide different results during the different phases of the grid layout logic. This issue causes assert violations like the one described in the bugs listed below. The new Baseline Alignment logic is now integrated in the Grid Track sizing algorithm. Hence, we need to ensure that an item that participates in any baseline alignment context during the track sizing also does during the alignment phase, at the end of the grid layout logic. In order to achieve that, this CL forces a new computation of the Baseline offsets during the step 3 of the Grid sizing algorith, since during this step the available space is not indefinite anymore. It's worth mentioning that this change assumes the issue grid items being excluded and included of Baseline Context during the different phases of the Grid sizing algorithm, which I hope we can clarify in the issue [2] I filed for the CSS WG. [1] https://drafts.csswg.org/css-grid/#fr-unit [2] w3c/csswg-drafts#3046 Bug: 867833, 874861, 876593 Change-Id: I668d399b920c9280a8e20b3e8362f562eded4770 Reviewed-on: https://chromium-review.googlesource.com/1177757 Reviewed-by: Sergio Villar <svillarigalia.com> Reviewed-by: Emil A Eklund <eaechromium.org> Commit-Queue: Javier Fernandez <jfernandezigalia.com> Cr-Commit-Position: refs/heads/master{#587799} -- wpt-commits: 16e4b911814b15f308f39cb06e5ac8b790608d37 wpt-pr: 12529 UltraBlame original commit: 7a1e05b09e40b019b67ba54e64e983fcd8b30d0e
…tion would change https://bugs.webkit.org/show_bug.cgi?id=232617 Reviewed by Javier Fernandez. Source/WebCore: According to https://drafts.csswg.org/css-grid/#algo-flex-tracks, when row height is indefinite, for each grid item that crosses a flexible track, we run the track sizing algorithm under a max-content constraint to find the flex fraction. Then we work out the grid container height as definite, which may cause the flex fraction change. At this point, we need to repeat the track sizing algorithm for row and layout the grid for real. The current implementation doesn't repeat the track sizing algorithm for row. The complication with calling RenderGrid::repeatTracksSizingIfNeeded() for flex max-sizing is that it might change a grid item's status of participating in Baseline Alignment for a cyclic sizing dependncy case, which should be definitively excluded. See w3c/csswg-drafts#3046 for more details. This issue should be handled in a seperate bug. This CL only handle test cases that don't have baseline alignment specified. * rendering/GridTrackSizingAlgorithm.cpp: (WebCore::GridTrackSizingAlgorithm::initializeTrackSizes): (WebCore::GridTrackSizingAlgorithm::setup): (WebCore::GridTrackSizingAlgorithm::reset): * rendering/GridTrackSizingAlgorithm.h: * rendering/RenderGrid.cpp: (WebCore::RenderGrid::repeatTracksSizingIfNeeded): (WebCore::RenderGrid::layoutBlock): * rendering/RenderGrid.h: LayoutTests: Unskip two tests that are passing. * TestExpectations: Canonical link: https://commits.webkit.org/244532@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@286148 268f45cc-cd09-0410-ab3c-d52691b4dbfc
…tion would change https://bugs.webkit.org/show_bug.cgi?id=232617 Reviewed by Javier Fernandez. Source/WebCore: According to https://drafts.csswg.org/css-grid/#algo-flex-tracks, when row height is indefinite, for each grid item that crosses a flexible track, we run the track sizing algorithm under a max-content constraint to find the flex fraction. Then we work out the grid container height as definite, which may cause the flex fraction change. At this point, we need to repeat the track sizing algorithm for row and layout the grid for real. The current implementation doesn't repeat the track sizing algorithm for row. The complication with calling RenderGrid::repeatTracksSizingIfNeeded() for flex max-sizing is that it might change a grid item's status of participating in Baseline Alignment for a cyclic sizing dependncy case, which should be definitively excluded. See w3c/csswg-drafts#3046 for more details. This issue should be handled in a seperate bug. This CL only handle test cases that don't have baseline alignment specified. * rendering/GridTrackSizingAlgorithm.cpp: (WebCore::GridTrackSizingAlgorithm::initializeTrackSizes): (WebCore::GridTrackSizingAlgorithm::setup): (WebCore::GridTrackSizingAlgorithm::reset): * rendering/GridTrackSizingAlgorithm.h: * rendering/RenderGrid.cpp: (WebCore::RenderGrid::repeatTracksSizingIfNeeded): (WebCore::RenderGrid::layoutBlock): * rendering/RenderGrid.h: LayoutTests: Unskip two tests that are passing. * TestExpectations: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@286148 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Lets consider the following example:
My doubt is whether or not the orthogonal item in column 2 can participate in baseline alignment along the column-axis, honoring the align-items property.
Assuming that a flexible track on a indefinite sized container should be considered as a content-sized track (this should be clarified in issues #3042 and #3044), in this case we have a situation where we can't determine this condition consistently during the different steps of the track sizing algorithm.
https://drafts.csswg.org/css-grid/#algo-overview
During step 2 we have to use the baseline shims so that they contribute to the size of the track; hence, we have to compute the baseline shims just before computing the tracks intrinsic sizes.
https://drafts.csswg.org/css-grid/#algo-baseline-shims
It's important to notice that we implement this shim computation as part of the track sizing algorithm, so that we can run it again in step 3, if necessary (eg. orthogonal items). This is an implementation decision, since the spec doesn't specify when the baseline shims must be computed; it just state when they should be applied.
So, at this point, since we are under indefinite height, we should consider the flexible track as content-sized; hence, since the orthogonal item has 'auto' inline-size, there is a cyclic dependency that implies the item should not participate in baseline alignment along the column-axis.
https://drafts.csswg.org/css-grid/#column-align
Then, we enter it step 3 of the grid sizing algorithm:
We are indeed in this scenario, so we have to repeat steps 1 and 2. This will include (that's what we should clarify in this issue) the computation of the baseline shims. Although these shims shouldn't change because of the different sizes resolved in this step, it's possible that items that didn't participate in baseline before are now allowed to do so.
The key is that for this step 3, the height is not indefinite anymore, so theoretically, we shouldn't consider the flexible tracks as content sized. The result is that the orthogonal item participates now in the baseline alignment.
is this the behavior we want ? The following pictures shows how the example above would be rendered:
The text was updated successfully, but these errors were encountered: