[css-align] baseline content-alignment shouldn't be able to change intrinsic sizes

[dbaron]

The section on baseline content alignment ends with the sentence:

This can increase the intrinsic size of the box.

It's not clear how this is supposed to work, for two reasons:

• intrinsic sizes are a function of the content and styles of a box and its descendants, whereas the amount of size change needed for baseline alignment depends on other elements in the baseline-sharing group
• it seems like there's a potential for loops here, although I haven't thought this through

[javifernandez]

I think the issue #1039 I filed some time ago is quite related to this one. I'm still fighting against this concept in the implementation for Blink and WebKit and I still have many doubts.

[frivoal]

This seems to be a similar problem to the one faced by the line-grid in #880.

[fantasai]

Another related issue: #1365

[tabatkins]

Tables adjust the size of their cells when things are baseline-aligned. Grid and Flexbox need to do so too; otherwise, you'd get results like , where anything that had to move down to align is likely to overflow. This would make baseline alignment entirely unusable within auto-height containers.

Currently, the spec attempts to address this by including these adjustments in the intrinsic sizes of the aligned items. Are you suggesting there is some other way to get this behavior? If so, how? :)

[javifernandez]

I understand why we need to let grid/flex items to adjust their sizes when they are baseline-aligned. My doubts came from the following facts that we have to integrate with this behavior:

• item's container intrinsic size must be determined without needing to laid out the items.
• once items are baseline-aligned during layout, what should we do with containers with intrinsic size dimensions ? eg, fit-content, min-content, ...

[dbaron]

(I'll assume horizontal writing modes here so I can write "height" and "width".)

The heights of table cells are not determined from intrinsic sizes. They're a result of layout. Intrinsic sizes only exist as widths; there's no such thing as an intrinsic height in table layout (and I've objected to the addition of such a concept in sizing, since I don't think it makes sense).

Though I'm not entirely sure what your image is an image of...

[javifernandez]

Though I'm not entirely sure what your image is an image of...
The image is a grid layout, with an orthogonal element in the second column using ahem font.

I agree with your statement about height being the result of a layout, so it's not an intrinsic size. However, the issue this image is trying to illustrate (see issue #1365) could lead to inline-axis overflow,
since grid layout allows baseline alignment along the row-axis. Are you suggesting that we should only avoid changes in the intrinsic width ?

I understand Tab comment on the need of adjusting the container's size after applying baseline alignment, however, issue#1365 have several points that makes such behavior difficult to implement inside the grid tracks sizing algorithm, specially regarding the following condition:

Then, if the min-content contribution of any grid items have changed based on the row sizes calculated in step 2, steps 1 and 2 are repeated with the new min-content contribution and max-content contribution (once only).

[dbaron]

Exactly how problematic this is may also be clearer after the issues in the final paragraph of #2890 (comment) are resolved.