Repository navigation
[css-display] Should anonymous boxes always inherit through the box tree? #1118
Description
CSS Display says
anonymous boxes (which only exist in the box tree) inherit through their box tree parentage
I think this implies an anonymous box doesn't inherit from its parent element if the parent has display: contents, because that means
The element itself does not generate any boxes
For example,
<section>
<div>Foo</div>
</section>section {
color: red;
}
div {
color: green;
display: contents;
}Foo is wrapped inside an anonymous inline box, so according to the quote above, it should inherit the red color from its parent box, which is the box of the section, because the div does not generate boxes.
But this seems wrong, because if we had
<section>
<div><span>Foo</span></div>
</section>then the span would inherit the green color from the div through the element tree.
In Firefox and Chromium the text in the first example is green as expected, I think it's just that the spec is confusing.
Activity
[-][css-display] Should anonymous boxes really inherit through the box tree?[/-][+][css-display] Should anonymous boxes always inherit through the box tree?[/+]FremyCompany commentedon Apr 12, 2017
Can we add a test case here?
tabatkins commentedon Apr 12, 2017
Yeah, I think that terminology is wrong now. We should probably define, for each anonymous box, what its "originating element" is, same as pseudo-elements have, which determines what it inherits from.
css-meeting-bot commentedon Apr 19, 2017
The CSS Working Group just discussed Should anonymous boxes always inherit through the box tree?.
The full IRC log of that discussion
tabatkins commentedon Apr 19, 2017
fantasai and I seem to disagree on the behavior - she think the first example should have red text; i find it vaguely horrifying that inserting a non-styled span should have dramatic effects on inheritance in this sole instance.
Assuming we go with "everything should be green", doing this rigorously seems to require us 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. I'm down with this.
(Alternately, we can do some handwavey "the element that would generate the text's parent box, if it wasn't display:contents". But that's handwavey and nasty; I'd much prefer to get a better, more rigorous description of text in the CSS model.)
FremyCompany commentedon Apr 19, 2017
Wouldn't it be unfortunate if
would result in "Chapter 1: " and "Introduction" having different colors?
bzbarsky commentedon Apr 19, 2017
For what it's worth, this is what Gecko does anyway. I can't speak for other implementations.
Loirooriol commentedon Apr 20, 2017
Introducing text boxes would need to rewrite inline layout algorithm in order to take them into account. As I said in #1249 (comment), I think it would be easier (both conceptually and to spec) to handle this by wrapping each contiguous run of text that is directly contained inside an element into an anonymous inline box, which would inherit from the element. In practice it should almost be the same. Thoughts?
astearns commentedon May 2, 2017
I believe the next step is for @tabatkins to come up with a proposal, so I'm removing the agenda+ waiting for that.
tabatkins commentedon May 15, 2017
Proposed changes:
Display - Define that the element tree contains text as well as elements.
Cascade - Define how inheritance works over text
Scoping - Rigorously define how text moves around due to shadows
Text - Maybe some minor changes to rigorously talk about text?
Text Decor - clarify whether the magic decoration inheritance is thru the box tree or element tree
maybe more?
@fantasai and I are gonna explore what the actual edits need to be before we present this to the WG.
20 remaining items
tabatkins commentedon Jun 5, 2017
Yes, that would of course be normal and expected. As far as I can tell that's not germane to this issue, tho? Again, the issue is that, without something like what's described here, the inheritance behavior of text depends on whether or not its immediate parent element generates a box. This is inconsistent with how inheritance works for elements, thus the surprise.
I'm very confused by this statement. You're correct that being styled via inheritance from a display:contents element isn't surprising. That's what we're trying to ensure will happen! Right now, as vaguely written, text won't inherit from a display:contents parent element; our concept of "text nodes" carrying styles ensures that it does, like normal elements do.
To help alleviate my confusion about what position you're advocating for, @anttijk, can you quickly say what color you expect the text to be in the two examples in the first comment?
anttijk commentedon Jun 6, 2017
We didn't have a case where you could have non-box-generating element with visible text children before display:contents. There is nothing to be inconsistent with; the case is new. It seem that the simplest solution would be that the text properties are defined by the parent box (which is also the specced behavior before the proposed changes here).
I don't find it particularly surprising that a non-box generating element doesn't affect child text node style. In fact that's what I would expect. The text node is behaving as if it was a direct child of the box-generating ancestor, something that is easily explained.
Perhaps there is some better example than has been presented here so far why this is a bad or inconsistent behavior? The argument in the original post is that it is surprising that an unstyled element is still being affected via inheritance. I was curious why people found it surprising.
tabatkins commentedon Jun 6, 2017
Of course the case is new. But before
display:contents, "text nodes exists in the element tree, and inherit from their parent element" and "text exists in the box tree, and inherits from its parent box" were indistinguishable. Both behaviors had exactly the same effect (none of the box-tree manipulations that existed prior todisplay:contentschanged the parent box of text in a way that would change the inheritance results).Thus, you could pretend that inheritance always worked thru the element tree, for all styling. Now, we suddenly have a case that breaks the symmetry, and we have to decide whether we prefer "inheritance always goes thru the element tree" or "inheritance is thru the element tree for elements, and thru the box tree for text". The former is simpler overall, but requires introducing some new concepts to CSS; the latter requires no new spec concepts, but introduces an asymmetry and results that at least some people find surprising.
Neither way is particularly difficult for implementations, as far as I can tell, and thus I strongly prefer the one that doesn't produce a behavior asymmetry.
No, you seem to be misunderstanding the example? It's pointing out the difference in the style of text; the span is used to introduce the styling difference, it's not the point of the example.
The argument in the example is that it would be surprising if the two
targetelements in the markup below ended up with differentcolorvalues:In both examples,
targetshould have a computedcolorofgreen: in the first example,targetdirectly inherits it fromchild; in the second example,targetinherits fromwrapper, butwrapperjust inherits it fromchild, so it should be green as well. (This is standard, non-controversial CSS.)It's weird, then, that if you replace
<target />with raw text, you'd get a different result - it would be red in the first example, and green in the second. What's the justification for raw text acting differently here? Why, if I add a meaningless wrapper element that doesn't interfere with inheritance at all (for scripting purposes, perhaps), do I get a dramatic difference in inherited value?Our diff fixes the specs so that this all works consistently, whether it's an element or text.
anttijk commentedon Jun 8, 2017
@tabatkins Thank you for restating the basic facts of the case. The actual argument seems to boil down to a personal preference.
I don't think we should abandon the "only elements and pseudo-elements have style" invariant for this. It is valuable in explaining and understanding how CSS works. That this requires little or no spec changes is a bonus.
I'm opposed to making these changes. CSSWG should just clarify that text style is determined by the box tree (if it is currently unclear).
I understand the example perfectly and already explained why I don't find the behavior surprising at all.
frivoal commentedon Jun 8, 2017
This seems less important than the "adding a non styled span in the middle inline content has no effect on rendering" invariant. If we could keep both, that'd be great. But as it seems we cannot, this one seems more important to preserve.
anttijk commentedon Jun 8, 2017
@frivoal There is no such thing as "non-styled span" in a rendered document. In this case the span is getting styled via inheritance which I find no more surprising than being styled by explicit "span { color:green }".
frivoal commentedon Jun 8, 2017
@anttijk I meant a span on which there is no specified styles.
fantasai commentedon Jul 5, 2017
@anttijk It is a general principle here that
a bit of textanda <span>bit</span> of text, where<span>has no style rule applying to it, render identically. This invariant is more important than any intuition about how things should work.[css-display] 各種更新
[css-cascade][css-flexbox][css-grid] Apply diff, per resolution. Fixes …
Text nodes with display:contents parent should render as if they were…