[css-display] Sort out interaction of "display:contents" with font-size and line-height

[bzbarsky]

CSS 2.1 has an invariant that can be summarized as follows: "any piece of text is contained in an inline box whose computed values for font-size and line-height match those of the text". That's to the extent that text has computed values at all, of course.

Now consider this testcase:

<div style="border: 1px solid black; font-size: 10px;">
   <span style="display: contents; font-size: 50px;">Text</span>
</div>

What is the expected layout? In terms of the box tree, the <span> doesn't exist. The box tree is constructed as if "Text" were a child of the <div> and per https://www.w3.org/TR/CSS21/visuren.html#anonymous (which nothing supersedes, afaict) there is an anonymous inline box whose computed font-size is "10px" and computed line-height is "normal".

Obvious questions:

1. What is the actual size of the text? Is it 10px or 50px, and why? That is, does text have independent computed font-size even though it's not actually a box in the box tree?
2. What is the used value of line-height for the anonymous inline and why? For the block and why?
3. If the <span> had a line-height specified, would that have any effect on anything? As far as I can tell from current spec language, no, because the text itself is not a box and hence does not participate in the line layout algorithm. What participates is the anonymous inline wrapping it, and that has a line-height that doesn't depend on the <span> in any way.
4. If the <span> has a font-family style that differs from that of the <div>, what font is used by the text?
5. If the <span> has a font-family style that differs from that of the <div>, which font is used to determine the ascent/descent of the anonymous inline box? Presumably that of the <div>, since that's what it inherits per the linked spec above. But that can be quite different from the actual ascent/descent of the text involved; seems wrong to me.

Basically, it would make the most sense to me if the anonymous inline for a piece of text inherited from the parent element of the text, not from the block. Without display:contents those are the same thing, but with display:contents they're not the same at all.

Note also that this would mean that this testcase:

<div style="border: 1px solid black; font-size: 10px;">
   <span style="display: contents; font-size: 50px; font-family: Times">Text</span>
   <span style="display: contents; font-size: 20px; font-family: Arial">Text</span>
</div>

would need two separate anonymous inlines, whereas CSS2.1 somewhat implies that this case would only have one anonymous inline. Of course without display:contents the number of anonymous inlines wrapping a piece of text, is not observable, nor are their boundaries....

[Loirooriol]

I think display: contents would be saner if each contiguous run of text that is directly contained inside an element with display: contents was wrapped in an anonymous inline box. That anonymous box would inherit from the element with display: contents, not through the box tree. I think this would also solve #1118.

This would have implications like Foo and Bar becoming distinct flex items in

<div style="display:flex">Foo<span style="display: contents">Bar</span></div>

which I don't think is bad.

[bzbarsky]

In this testcase:

<span style="display: contents">abc <span style="display: contents">def</span></span>

is there one run of text or two runs of text? I think you'd propose two, right?

[Loirooriol]

Yes, I think they should be two runs of texts, each one in its anonymous inline box wrapper. Otherwise different parts of the text can have different styles despite being in the same box, which doesn't seem intuitive. In my opinion, it seems more natural for CSS to solve this with anonymous boxes instead of introducing text nodes in the box tree with their own properties.

[Loirooriol]

In fact, would it have any impact if runs of text directly contained inside an element were always wrapped in anonymous inline boxes, independently on display: contents? Flex and grid already do this (the anonymous inline box is then blockified). I believe other layouts wouldn't be affected.

When I say 'element' I include ::before and ::after pseudo-elements.

[tabatkins]

Yes, this is another instance of #1118, and I think will be solved by that when I address it in the way I suggested in #1118 (comment).

Namely, "text" becomes an object capable of having properties and interacting in inheritance. In bz's first example, the text inherits the "text-size: 50px" and sizes accordingly, regardless of the presence of display:contents. His other questions are answered similarly - for all inherited properties, the text inherits its value from the span.

[bzbarsky]

Just defining text as something that has properties is not enough. You also have to change the actual algorithm of inline layout to consider the text boxes. Right now it explicitly does not, afaict.

[emilio]

Just a side note, my reading of the spec to think that the line box height should be the one of the text + 2 times the half-leading was from https://www.w3.org/TR/CSS21/visudet.html#inline-box-height:

The height of the inline box encloses all glyphs and their half-leading on each side and is thus exactly 'line-height'.

But of course that's contradictory with https://www.w3.org/TR/CSS21/visuren.html#anonymous in this case, in the case the font-size of the text should the one specified in the display: contents span.

[bzbarsky]

The point is, the text itself isn't a box in the CSS spec right now. It's just a paint-time effect.

[tabatkins]

@bzbarsky Right, but this is still a #1118 dupe; that includes needing to make edits to Text to refer to the text nodes properly. Closing as dupe.