I'm having problems to implement this part of the CSS Box alignment spec for Grid Layout:

https://drafts.csswg.org/css-align-3/#baseline-align-self

When a box participates in first (last) baseline self-alignment, it is aligned as follows: the minimum necessary extra space is added between its start (end) edge and the alignment container edge to match its alignment baseline in that axis up to that of its baseline-sharing group. See §8.3 Aligning Boxes by Baseline. This may increase the intrinsic size contribution of the alignment subject.

First of all, let's resolve the abstractions for the Grid Layout model; the alignment container is the grid item's grid area (the grid tracks such items is placed on), while the alignment subject is the grid item (the box participating in first (last) baseline self-alignment).

So, the first consequence of what the spec states is that after calculating the baseline of the shared-group and aligning all its items based on that, it may imply that a content-sized track will see its size increased. This fact has some implications that I don't fully understand:

1- How we should resolve the items with relative size (percentages) ? Should their size be resolved using the new content-sized track's size ?

2- Content Alignment affects the final size of the grid area when items spans more than one track. The space distributed depends on the one available after completing the track sizing algorithm. For items with a relative size, we only know their actual size after applying the content alignment rules. However, if baseline alters the size of the tracks, how this would affect to the item's relative size ?

Please, @tabatkins @fantasai could you take a look at this issue ? Not that it's specially urgent, but I m afraid it gets lost, since it's not even tagged yet. Thanks.

And don't worry, nothing can get lost - GH makes it easy to see all the untagged issues so we can periodically assign all of them. ^_^

(Well, things on www-style don't get “lost” either; the archives are always there. The point being made is that untagged issues may not get handled in the queue if they remain untagged. :)

Anyway, @javifernandez, if I understand correctly this issue is about percentage resolution against a container that depends on the size of the item being percentage-sized, and the impact of content alignment on that case, specifically. Is that correct?

Yes, that's basically the problem. But it's even more complex/confusing when considering that the container's size also depends on the Baseline Alignment, which could eventually change the item's relative size.

My main concern is that baseline alignment altering the grid item's container (grid area) can lead to different issues; how that could affect to the grid container's intrinsic size ?

1- How we should resolve the items with relative size (percentages) ? Should their size be resolved using the new content-sized track's size ?

No. Grid doesn't have any special exceptions for making additional things definite, so %s resolve as normal: if the grid area is definite, they resolve accordingly; if not, they don't. See https://www.w3.org/TR/CSS21/visudet.html#the-height-property . This is completely unconnected from alignment.

2- Content Alignment affects the final size of the grid area when items spans more than one track. The space distributed depends on the one available after completing the track sizing algorithm. For items with a relative size, we only know their actual size after applying the content alignment rules. However, if baseline alters the size of the tracks, how this would affect to the item's relative size ?

I'm not sure I understand the confusion, but let's walk through an example. Let's say we have a 4-column grid, where the item in the last column spans three rows, and the first row has first-baseline alignment on all items.

First we size all the items in the row normally. Then we align them together. For this purpose, we consider the spanning item. This may cause some of the items to get shifted down more, as if they had more margin/padding on the top.

Then we size the rows: in the first step we consider only nonspanning items, so we size the first row accordingly. This will include the alignment “margin/padding" that we calculated for these items. Then we adjust the rows to accommodate the spanning items if necessary.

That's it. We don't need to consider percentage sizes, because they don't resolve against auto-height rows.

~fantasai and TJ

On a related note, Tab filed #1319 wrt percentage resolution of grid item sizes in content-sized tracks.

Let's take your example to introduce the doubts I have regarding the issue of baseline affecting the intrinsic size.

First we size all the items in the row normally.

As the items are relatively sized, we need to assume their container height is auto, so for the matter of track sizing alg, row will be sized as if items were auto sized. As per Tab issue #1319, we will resolved the item's size based on the "definite" final size of the row track.

Then we align them together.

If I understood correctly, you are suggesting that we run the baseline alignment algorithm before the tracks sizing algorithm. This could work for non-empty grid items, but it will have some implications for empty or items that need to synthesize their baselines (replaced or orthogonal to the baseline axis). In case of synthesized baseline we will need to know the actual item's height to compute the baseline alignment offsets.

Then we size the rows: in the first step we consider only nonspanning items, so we size the first row accordingly. This will include the alignment “margin/padding" that we calculated for these items. Then we adjust the rows to accommodate the spanning items if necessary.

I admit that I might add some noise mentioning content alignment here, but it matters as well because the content-distribution gaps will be based on the available space after running the tracks sizing algorithm; depending on when the baseline alignment logic happens it may have some impact on the final available size. Hence, since items spanning more that one rows have grid areas which size depends on such content-distribution offsets, the order of the different alignment procedures matters. this may also have some impact when we resolve the percentage sizes later.

But let's leaving aside for a moment the content-distribution issues. What it really worries me is how the baseline alignment offset affects the intrinsic size of the grid areas. Since that's what the spec states, we would need to run the baseline alignment before the track sizing. But as synthesized baselines depend on the resolved heights of the item we should run it after determining the grid item's area.

Let's use this simplified example to illustrate the issue:

.grid {
  display: grid;
  font: 20px/1 Ahem;
  grid-auto-columns: 100px;
  align-items: baseline;
}
.i1 {
  background: magenta;
  height: 50%;
}
.i2 {
  background: cyan;
  grid-column: 2;
  font-size: 40px;
}
.i3 { background: yellow; }
<div class="grid" style="height: 100px;">
  <div class="i1"></div>
  <div class="i2">X</div>
  <div class="i3">p</div>
</div>

Let's modify a little bit @javifernandez's example and try to re-explain the issue.

<div style="display: inline-grid; border: solid thick; margin: 100px;
            grid-auto-columns: 100px; align-items: baseline;">
  <div style="height: 50px; background: cyan;"></div>
  <div style="height: 200%; background: magenta;"></div>
  <div style="height: 25px; grid-column: span 2; background: yellow; opacity: 0.7;"></div>
</div>

The current output in Chrome is the following:

The reason why it looks like this is basically:

• Initially we check the height of the element sin the first row.
  The 1st item (the cyan one) has a fixed height of 50px.
  The 2nd item (the magenta one) has a percentage height, as the track is auto, it uses its content size which is 0px at that point.
• We take the maximum of these sizes 50px and 0px as the baseline offset.
• Then the final size of the items, once the track size is resolved to 50px, is 50px for the 1st item and 100px (200% of 50px) for the 2nd one.
• We use the baseline offset to place the items:
  First item: 50px - 50px = 0px (no offset).
  Second item: 50px - 100px = -50px.

So the 2nd item (the magenta one) overflows on the top of its grid area (the first track).

Our question is if this is (or not) the expected behavior.

Or if it should be something like this:

Where the first track would still be 50px, but the 1st item (the cyan one) will be moved 50px and the 2nd item (the magenta one) will be aligned to the top of the track.
In that case both items will be overflowing its grid area (the first track) at the bottom.

What do you think? Thanks!

Hmm, this is the same problem as #1365, with an overflowing vertical text using baseline-alignment. In both cases, the overflowing item gets its height from the container, and the baseline alignment increases the size of the container, making it continue to overflow -- we end up just reproducing the original bad situation, but bigger!

So, I think it's clear that "baseline alignment alters intrinsic size" is too simplistic. There's something more targetted that needs to be done, to allow elements to baseline align, but without allowing the overflowing element to resize itself and continue to overflow. We're not quite sure what this thing is, tho. Let's try to whiteboard it in Paris and see if we can figure this out.

Current idea is to incorporate extra space added due to baseline alignment into the Resolve Intrinsic Track Sizes step, span level by span level.

OK, I just checked in some proposed changes (as green <ins> text) to Resolve Intrinsic Track Sizes (see changeset).

@javifernandez @mrego @atanassov Have a look and let me know what you think?

Computing baseline alignment as part of the Resolve Intrinsic Size may work, although I still need some time to do some preliminary implementation to understand its complexity and potential issues.

However, I'm not sure I fully understand this paragraph:

The extra space required to accommodate an item’s participation in baseline alignment is distributed by calculating the shims required for including their participation with already-considered items (those of lesser or equal spanning size) and distributing the shims’ space as if it were part of the shimmed items’ original size contribution.

Among which objects/items the extra space is distributed ?
Which are those elements 'already-considered' ?
What's the "shimmed item's original size' ?

I think this statement is really confusing. Would it be possible to have a example of how it should be applied ?

I've got another doubt regarding this new statement:

https://drafts.csswg.org/css-grid/#algo-content

1- Size tracks to fit non-spanning items
...
In all cases, if any items participate in baseline alignment, perform baseline alignment to calculate the extra space it would require, and add that to the track’s base size and/or growth limit as needed.

In some cases, like the one described in issue #1365, the extra space added by the baseline alignment will depend on the base size and growth limit. Should we compute the baseline alignment using both values as item's container, adding each one to the base size and growth limit respectively ?

Also, after analyzing deeper the implications of the proposed change, I think it doesn't solve the issues described by mrego in #1039 (comment)

I have another question regarding the statement above:

1- Size tracks to fit non-spanning items
...
In all cases, if any items participate in baseline alignment, perform baseline alignment to calculate the extra space it would require, and add that to the track’s base size and/or growth limit as needed.

In case of orthogonal items we need to know the grid area size in order to compute properly its synthesized baseline. At this stage, we don't known it obviously as that's precisely what we are computing here. What should we do in this case ?

We've tried a different approach here - we do an early collection of baseline-aligned things, calculate how tall they are and baseline align them, then add "shims" to their margin to maintain this alignment thru the intrinsic sizing calc.

It doesn't really handle items whose size depends on the size of the track; we're trying to cover that in #1365. Let us know what you think of these edits and also #1365's edits, or any other ideas that you think might be better.

I think these changes make sense. They address the issues at the same time they simplify considerably the implementation. Please, consider my comments on #1365 asking for further explanations about how and when to ignore these circular sized items from the baseline-alignment logic.

The Working Group just discussed Baseline self-alignment may affect the intrinsic size contribution of the alignment subject, and agreed to the following resolutions:

• RESOLVED: Accept the proposed change in the last comment of https://github.com/w3c/csswg-drafts/issues/1039

If I got it right, my previous example in comment #1039 (comment) would be covered by #1365. As the percentage height of the item depends on the height of the track so the element won't participate in the baseline alignment.

So let's use a new example that will be fixed thanks to this edit.

<div style="display: inline-grid; border: solid thick;
            grid-template-rows: 100px 100px; grid-auto-flow: column; justify-items: baseline;">
  <div style="font-size: 100px; background: magenta; writing-mode: vertical-lr;">Foo</div> 
  <div style="font-size: 30px; background: cyan; writing-mode: vertical-lr;">Bar baz baa barr bazz baaa</div> 
  <div style="grid-row: span 2; background: yellow;">foobar</div> 
</div>

I'm attaching an image with the result in the different browsers and the output with the current proposal.

In this case all browsers will need to update their implementation.

In my opinion, the idea of using shims during the track sizing is the way to go. At least in the case of WebKit and Blink implementation it doesn't imply huge changes or more complexity. It also address the intrinsic size issues derived from the baseline-alignment and avoids the extra iteration of the sizing algorithm.