Repository navigation
[css-display][css-flexbox][css-grid] Interaction of 'display: contents' and 'run of text' #1281
Description
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.
Activity
MatsPalmgren commentedon Apr 23, 2017
The CSS Display spec says:
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 commentedon Apr 23, 2017
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 commentedon Apr 24, 2017
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 commentedon Apr 25, 2017
Yes, it also seems a bit strange to me that text nodes with different styles become a single run of text. I think
display: contentswould be more sane if text directly contained in adisplay: contentselement was wrapped in an anonymous inline box. In that case they would become different flex items.bradkemper commentedon Apr 25, 2017
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 commentedon Apr 25, 2017
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 commentedon Apr 25, 2017
@bradkemper Yes, currently
display: contentsis not well defined, see #1118 and #1249. I think it might have worked if inheritance skipped elements withdisplay: 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 commentedon Apr 26, 2017
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:contentthe separate flex/grid item seems much more problematic to me. I considerdisplay:contentsas 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 withdisplay:contentsend 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 ofdisplay: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 commentedon Apr 26, 2017
@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: contentsallows 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 indisplay:contents.bradkemper commentedon Apr 27, 2017
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 commentedon Apr 27, 2017
@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 likedisplay:inline), and I strongly disagree to remove it. The contents of the element withdisplay:contentsmay 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 withdisplay:contentsends 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?
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-heightwhich affects the layout, and browsers are able to handle this. Maybe introducing something like 'text box' concept would be useful for both cases?Bug 1360508: Use the parent's frame style context when handling text-…
Bug 1360508: Use the parent's frame style context when handling text-…
Bug 1360508: Use the parent's frame style context when handling text-…
tabatkins commentedon May 16, 2017
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 commentedon May 16, 2017
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 commentedon Jul 5, 2017
I've committed the diff, so closing this issue as solved.
Bug 1360508: Use the parent's frame style context when handling text-…
Bug 1360508: Use the parent's frame style context when handling text-…
Bug 1360508: Use the parent's frame style context when handling text-…
Bug 1360508: Use the parent's frame style context when handling text-…