[css-align][css-grid] Baseline self-alignment may affect the intrinsic size contribution of the alignment subject.

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 ?

@tabatkins

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

@javifernandez

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

@javifernandez

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.

[css-grid] Baseline alignment inside the tracks sizing algorithm

Bug 1438730 [wpt PR 9553] - [css-grid] Baseline alignment inside the …

Navigation Menu

Repository navigation

[css-align][css-grid] Baseline self-alignment may affect the intrinsic size contribution of the alignment subject. #1039

29 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-align][css-grid] Baseline self-alignment may affect the intrinsic size contribution of the alignment subject. #1039

Description

Activity

javifernandez commented on Mar 30, 2017

tabatkins commented on Mar 31, 2017

fantasai commented on Apr 7, 2017

javifernandez commented on Apr 7, 2017

fantasai commented on May 2, 2017

fantasai commented on May 3, 2017

javifernandez commented on May 9, 2017

mrego commented on May 9, 2017

tabatkins commented on Jul 5, 2017

29 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions