[css-align] Apply align-content to replaced elements

[MatsPalmgren]

The spec for align-content says:

Applies to: block containers, multicol containers, flex containers, and grid containers

An image is not a block container, nor any of the other containers listed.

So, per those definitions, align-content:baseline does not apply to an <img> grid item.

However, the spec for Baseline Content-Alignment says for Grid items:

A grid item participates in first/last baseline content-alignment in its startmost/endmost row or column (whichever is parallel to its inline axis) and if its computed align-content is first baseline/last baseline.

A strict reading of the spec implies that Baseline Content-Alignment does not apply to an <img> grid item since the align-content property doesn't even apply to images. Is this is the intention of the spec? I see no particular reason why images, for example, shouldn't be allowed to participate in baseline alignment using align-content:baseline.

[Loirooriol]

Note that (https://drafts.csswg.org/css-cascade/#computed)

The computed value exists even when the property does not apply

Since the condition only checks the computed value, it seems that align-content doesn't need to apply in order to let images participate in baseline alignment... but if the property has some effect then it should apply.

[fantasai]

@MatsPalmgren Content alignment requires adding space inside the element, but replaced elements don't have internal CSS layout. So I'm unsure how they could be participating?

Certainly they can participate in self-alignment, but that's a different thing.

[fantasai]

Added "non-replaced" to the description of when baseline alignment applies, so at least there's no confusion on the image grid item case.

[MatsPalmgren]

Content alignment requires adding space inside the element, but replaced elements don't have internal CSS layout. So I'm unsure how they could be participating?

First, talking about elements in this context makes no sense, since CSS layout is based on boxes. Second, "adding space" here refers to increasing the padding and images certainly have padding, for example:

<img style="border:1px solid; padding:30px;" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABgAAAAMCAIAAAD3UuoiAAAAGklEQVQoz2Nk%2BP%2BfgRqAiYFKYNSgUYOGp0EA%2BQMCFrJdTgsAAAAASUVORK5CYII%3D">

So why exactly shouldn't align-content:baseline apply to images (and any other box type that applies padding) by increasing that padding?

[fantasai]

So what you're asking, is not about baseline alignment specifically, but to have align-content and justify-content, in general, apply to replaced elements, correct?

[fantasai]

I will note that replaced elements do already have the object-fit and object-position properties applying to them...

[tabatkins]

Huh, I... did not realize that padding worked on images. Makes sense, I guess, since padding is outside the content area.

So what you're asking, is not about baseline alignment specifically, but to have align-content and justify-content, in general, apply to replaced elements, correct?

That does appear to be it, yes.

I will note that replaced elements do already have the object-fit and object-position properties applying to them...

I think there's a reasonable interaction here - object-* properties still just size/align the content within the content box, but the *-content properties would effectively apply "magic padding" to align the content box as specified. normal would resolve to stretch for replaced elements, meaning no magic padding.

[css-meeting-bot]

The CSS Working Group just discussed css-align] Apply align-content to replaced elements #4545.

The full IRC log of that discussion

<dael> Topic: css-align] Apply align-content to replaced elements #4545
<dael> github: https://github.com//issues/4545
<dael> TabAtkins: Mats wants the content alignment prop to apply to replaced elements. It adds magical padding. Replaced elements ca have padding on them. Easy theoretical model there's nothing wrong with having content alignment work.
<dael> TabAtkins: Seems fine to me. We hadn't thought of it. Similar to object fit and position, but separable because this adjusts outside content box
<dael> TabAtkins: I'm fine adding this in. Want to make sure; check temp of group
<dael> fantasai: Size of replaced element when not stretched?
<dael> fantasai: In order to align something within something need size of container and thing being aligned. Know container. Size of thing being aligned what's the size?
<dael> TabAtkins: intrinsic of content
<dael> fantasai: Is that useful? What does it mean if something w/o intrinsic size
<dael> TabAtkins: Stuff w/o intrinsic doesn't work. How useful, I don't know. Works in the model
<tantek> does this actually enable any new use-cases that aren't already solved by object-fit etc.?
<dael> fantasai: It's possible, but I don't know if it's useful. If not useful why do we spend time to define. What new use cases does this enable? Gotta do something or not worth effort.
<tantek> right if it's not useful (new use-cases, or great simplification of existing use-cases), we should not do it
<fantasai> s/define/define and test and implement/
<dael> TabAtkins: Unless anyone has ideas perhaps push back until we get a use case. Looking over issue from Mats there isn't one
<tantek> I'd leave the issue open to allow gathering of new use-cases
<dael> jensimmons: Wondering what reason was to file issue
<dael> dholbert: Might be easier to have it work than add an exception
<tantek> or ways to simplify existing use-cases. I trust mats had something in mind
<dael> Rossen_: If we don't know the reasoning it's a fair ask to go back and se what he replies with.
<dael> Rossen_: If it's pure theory it's one thing but if there's actual use cases...grid is a common layout that's being used more and more with replaced content for various image and media presentation. Ideally he'll have an example
<dael> Rossen_: Let's continue in the issue

[fantasai]

@MatsPalmgren CSSWG discussed your suggestion (see above), but we didn't see any strong use cases. So for the moment, it doesn't seem worth the implementation and testing effort to make this work. If there are significant use cases you have, or others have, we're open to considering them, though.