W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2018

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

From: Javier Fernandez Garcia-Boente via GitHub <sysbot+gh@w3.org>
Date: Thu, 23 Aug 2018 14:29:51 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-353408559-1535034590-sysbot+gh@w3.org>
javifernandez has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-grid] Inconsitence of the "intrinsically-sized track" concept when using flexible tracks ==
Lets consider the following example:

```
<div style="display: grid; font-family: Ahem; border: solid; width: 200px; grid: minmax(0px, 1fr) / 100px 100px; align-items: baseline">
  <div style="grid-column: 1; background: blue; font-size: 50px;  padding-bottom: 25px">É</div>
  <div style="grid-column: 2; background: green; grid-row: 1; writing-mode: vertical-lr">ÉÉ É ÉÉ ÉÉÉÉ É</div>
</div>

```

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
> 2. Next, the track sizing algorithm resolves the sizes of the grid rows, using the grid column sizes calculated in the previous step and the effective column gap sizes after applying justify-content. 

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
> Shim baseline-aligned items so their intrinsic size contributions reflect their baseline alignment. For the items in each baseline-sharing group, add a “shim” (effectively, additional margin) on the start/end side (for first/last-baseline alignment) of each item so that, when start/end-aligned together their baselines align as specified. 

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
> 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.

Then, we enter it step 3 of the grid sizing algorithm:

> 3. Then, if the min-content contribution of any grid item has changed based on the row sizes and alignment calculated in step 2, re-resolve the sizes of the grid columns with the new min-content and max-content contributions (once only), using the grid row sizes calculated in the previous step along with the effective row gap sizes calculated by applying align-content. 

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 not 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:

![baseline-and-flex-tracks](https://user-images.githubusercontent.com/2230241/44531715-bf343900-a6f1-11e8-8eb9-e6cf57e9514f.png)
 

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3046 using your GitHub account
Received on Thursday, 23 August 2018 14:29:53 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:35 UTC