[css-display][css-flexbox][css-grid] Interaction of 'display: contents' and 'run of text'

[Loirooriol]

Various specifications use the term 'run of text'. For example, CSS Flexbox and CSS Grid:

each contiguous run of text that is directly contained inside a flex container is wrapped in an anonymous flex item.

Each contiguous run of text that is directly contained inside a grid container is wrapped in an anonymous grid item.

But as far as I know, this term is not defined anywhere. So I don't know how it should interact with display: contents. For example, https://jsfiddle.net/p63c5uyt/

div {
  display: flex;
  flex-direction: column;
}
span {
  display: contents;
}

<div>Foo<span>Bar</span></div>

Should Bar appear next to or below Foo?

Both Firefox and Chrome consider that display: contents makes both Foo and Bar to be in the same run of text. This is not obvious to me.

Tab wants (#1118 (comment))

to define "text" as an object in the element tree that has properties (only set via inheritance), and which generates "text" in the box tree accordingly

not sure if this has any impact, given that Foo and Bar are different text nodes in the DOM.

[MatsPalmgren]

The CSS Display spec says:

For the purposes of box generation and layout, the element must be treated as if it had been replaced in the element tree by its contents [...]

which I think makes it's clear that Firefox and Chrome is implementing the intent of the spec for the given example (there's only one flex item).

[Loirooriol]

OK, but since I can't find any definition of "run of text", I was not sure if it was a box-generation-and-layout thingie, or a element-tree thingie.

[FremyCompany]

Hum that's weird. They would occupy in the same grid/flex area but have two different formattings? This seems a bit contradictory but I have no strong opinion. https://jsfiddle.net/p63c5uyt/1/

[Loirooriol]

Yes, it also seems a bit strange to me that text nodes with different styles become a single run of text. I think display: contents would be more sane if text directly contained in a display: contents element was wrapped in an anonymous inline box. In that case they would become different flex items.

[bradkemper]

Doesn't that defeat the purpose of it? It isn't supposed to generate any boxes. I don't see how it could take any styling of its own, once it was display:contents, if it didn't have its own box. Even font-size could affect layout. If it was just text, it wouldn't have its own color either.

I don't think this value is described very completely.

[bradkemper]

I mean, it is supposed to react to some things, like 'flex' as if it was a contiguous part of its parent and taking on its parent's non-inherited property values, but react to other properties as though it still was its own element.

[Loirooriol]

@bradkemper Yes, currently display: contents is not well defined, see #1118 and #1249. I think it might have worked if inheritance skipped elements with display: contents, but it doesn't. So there must be some thing which inherits the styles. Tab proposes introducing text boxes that inherit from the parent element, which presumably require rewriting the inline layout algorithm to take them into account. Then, I wonder if 'run of text' would mean 'run of text boxes' or 'run of text nodes in a text box'.

[SelenIT]

I see no problem with text of different formatting occupiying the same flex/grid area. Single runs of text with different formatting aren't new in CSS, they occur quite often because of the font fallbacks. Can we generalize the rules of this behavior and reuse it for our case?

Making element with display:content the separate flex/grid item seems much more problematic to me. I consider display:contents as a way to separate the visual hierarchy of boxes from the DOM hierarchy, with the ability of effectively converting the children of the element to the siblings of its siblings as one of the biggest advantage. So if the siblings of the element with display:contents end up in the inline formatting context, I strictly prefer to see the text content of this element in the same inline formatting context, and creating the separate flex/grid item for it — as if it was the inline-level element box — feels like it's against the purpose of display:contents.

So my suggestion is to treat 'run of text' as 'run of text nodes in a text box', or even just as 'run of differently formatted text fragments in a text box' — in the similar way as text rendered with different fonts of the font stack or bidirectional text is treated.

[Loirooriol]

@SelenIT From your description it seems you meant you want a run of text to be a run of multiple text box instead of a single text box, right? In the example from the first comment, Foo and Bar will need to be in different text boxes, because that's the mechanism which allows different styles, or that's what I understood.

I'm not interested in fonts so I don't know about font fallbacks. But I'm not convinced it's exactly the same, even if some character is not supported by the font and a fallback is used, its text box will still have the same specified font. display: contents allows adjacent text boxes to have different specified styles. So I believe the former is an intra text box phenomenon, and the latter is an inter one.

Anyways, I don't have a strong opinion, I just think some spec should clarify the meaning of 'run of text' when mixed with display:contents. Possibly this will need the 'text box' concept or whatever mechanism used to style text in display:contents.

[bradkemper]

Even though I find inheriting from a box that has been removed a bit surprising, I could see it being useful. I agree with @Loirooriol. Foo and Bar in the example should be in the same run of text, and children should become siblings.

[SelenIT]

@Loirooriol I can agree with any interpretation that would not require 'Foo' and 'Bar' in the example becoming separate flex items :). I believe that the ability to place content of different elements in the same 'run of text' (whatever that means) is one of the key advantages of display:contents (comparing to old values like display:inline), and I strongly disagree to remove it. The contents of the element with display:contents may be implemented as a separate text box, but this text box should never be 'blockified' etc. by itself. In my opinion, if the content of the element with display:contents ends up being a separate flex/grid item, it directly contradicts the requirement that 'the element creates no boxes'.

I agree with @MatsPalmgren that the current implementations of Gecko and Blink match the intent of the spec. I believe that the spec should reflect this behavior and this behavior should not be changed.

As I understand the comment by @bzbarsky, we already have the concept of styleable 'text', separate from 'anonymous inline box', in reality. May be we should specify it?

even if some character is not supported by the font and a fallback is used, its text box will still have the same specified font. display: contents allows adjacent text boxes to have different specified styles.

I didn't suggest it's exactly the same, but I see many similarities between these situations from the rendering perspective. Different characters in the same run of text already can have different actual values of line-height which affects the layout, and browsers are able to handle this. Maybe introducing something like 'text box' concept would be useful for both cases?

[tabatkins]

I agree in general: "Foo" and "Bar" should be in a single flex item, because there's no inline box to get blockified into a flex item in the first place! When #1118 is fixed, the layout algos will have a properly defined concept of "text" which we'll fix up flexbox and others to reference (probably we'll define the term "text run", meaning a maximal contiguous sequence of sibling texts in the box tree, and use that in most places).

[tabatkins]

Okay, we've proposed a diff in #1118 (comment) that resolves this issue. Let us know if there's something not accounted for.

(It supports the "Foo and Bar wind up in a single flex item" interpretation.)

[tabatkins]

I've committed the diff, so closing this issue as solved.