Repository navigation
[css-display] [css-text-decor] Propagation of text-decoration with display:contents #1136
Description
From CSS Text Decoration,
the decorations are propagated to all in-flow children.
From CSS Display, display: contents means
The element itself does not generate any boxes, but its children and pseudo-elements still generate boxes as normal.
Then, if a decoration is specified in an element which does not generate boxes, does the decoration propagate to the descendants which generate boxes?
display: contents does not affect inheritance, but text decorations are special because they propagate using a mechanism different than inheritance. I'm not sure if it is an element-tree thing, and thus the decoration should still propagate, or if it's a box-tree thing, and thus it shouldn't.
Example: https://jsfiddle.net/203oz4jr/
<div>Foo</div>div {
display: contents;
text-decoration: underline;
}Should Foo be underlined? It's underlined on Chrome, but not on Firefox.
Activity
Loirooriol commentedon Mar 28, 2017
OK, thanks. I filed https://bugs.chromium.org/p/chromium/issues/detail?id=705999
Loirooriol commentedon Apr 29, 2017
I guess it's the same for
opacity(here both Firefox and Chrome agree). Maybe there should some list of properties which usually affect descendants but apply to the box, so will have no effect withdisplay: contents.tabatkins commentedon May 15, 2017
I'm not sure I agree with @rune-opera; why should this propagate thru the box tree specifically? I can easily see it doing so thru the element tree instead. That is, I can see it going either way, and I want to make sure we're making the decision deliberately.
@fantasai makes the argument (in person) that a run-in merging into a paragraph should pick up the paragraph's text-decoration. That would imply that it propagates thru the box-tree. Any counter-arguments to this?
Loirooriol commentedon May 15, 2017
I think I have a counter-argument which suggests that it propagates thru the element-tree.
When an inline element contains a block-level element, the block splits the inline. So the block box ends up outside the two inline box fragments. But decoration in the inline is propagated to the block.
From https://drafts.csswg.org/css-text-decor-3/#line-decoration,
tabatkins commentedon May 16, 2017
While that is a reasonable tick in the "element tree" column, there's so many aspects of the propagation that only work in the box tree that I think it's best served by just being an explicit call-out exception in how it box-tree propagates.
@rune-opera Yup, that bug makes it pretty clear that propagation needs to be a box-tree concept, so that fixup can interrupt propagation properly.
Okay, so I think we can close this issue with the conclusion that decorations definitely propagate thru the box tree, and thus the interaction of decorations and display:contents is already well-defined. (In particular, in the OP's example, no decoration should be applied - the
divdoesn't generate a box, so no decoration is ever established on a box.)This work for everyone?
(Separately, @fantasai and I are now looking more closely at the propagation text, and realizing that the "applied to" paragraph is woefully underspecified.)
css-meeting-bot commentedon May 31, 2017
The CSS Working Group just discussed
[css-display] [css-text-decor] Propagation of text-decoration with display:contents, and agreed to the following resolutions:RESOLVED: define this as a box-tree conceptThe full IRC log of that discussion
<astearns> topic: [css-display] [css-text-decor] Propagation of text-decoration with display:contents<astearns> github topic: https://github.com//issues/1136
<tantek> astearns: propagation of text decoration
<tantek> TabAtkins: q: how do text decorations propagate? on what tree do they propagate? they are not inheritance. something after inheritance. on box tree? element tree? or something else magic?
<tantek> TabAtkins: there are several arguments for box tree, in particular compat constraints
<tantek> TabAtkins: if you have an inline with an underline
<tantek> TabAtkins: if you have a span underline ...
<TabAtkins> <span underline>foo <div>INTERRUPTION</div> bar</span>
<tantek> TabAtkins: if you have this
<tantek> TabAtkins: the foo and the bar get underlined, the INTERRUPTION does not
<tantek> TabAtkins: because the block has broken the span apart
<tantek> TabAtkins: if the decorations propagated through the element tree then the div would get the decoration
<tantek> TabAtkins: but if propagate thru the box tree then that is what we see
<tantek> dbaron: it is already specified in terms of the element tree, and just specifies that case
<fantasai> https://drafts.csswg.org/css-text-decor-3/#line-decoration
<tantek> TabAtkins: it is not well specified from what we can see
<tantek> dbaron: we impl it from a spec that was relatively clear
<tantek> fantasai: I believe that was 2.1
<tantek> fantasai: which does not distinguish between elements and boxes very well
<tantek> dbaron: it was readable in terms of elements, and describes that case as don't do this thing
<tantek> dbaron: it explicitly said that
<fantasai> https://www.w3.org/TR/CSS21/text.html#decoration
<dbaron> s/we impl/I believe we implemented/
<tantek> TabAtkins: that implies that display contents as implications on how we treat that
<tantek> TabAtkins: whether that affects the decision
<tantek> fantasai: it shouldn't make a difference element vs block tree in general, but it will affect once we have display content
<tantek> fantasai: question is whether you can propagate to text nodes which are new thing now
<tantek> TabAtkins: side question if you specify it on a ... element does it .... ?
<tantek> dbaron: in terms of that we impl on the box tree
<tantek> TabAtkins: according to r... so do we
<tantek> astearns: any other interop data?
<dbaron> we walk up the box tree, but through placeholders for out-of-flows
<tantek> fremy: technically I can try... in IE
<fantasai> s/..../propagate to its contents/
<fantasai> s/on a .../on a display:contents element/
<tantek> TabAtkins: I got it the opposite
<tantek> TabAtkins: fix up will interrupt decoration
<tantek> fremy: example?
<TabAtkins> https://bugs.chromium.org/p/chromium/issues/detail?id=553174
<tantek> TabAtkins: yes I have a CR example
<tantek> TabAtkins: this is interruption due to inline table. we are propagating, other browsers do not
<tantek> dbaron: beware of tables when testing text-deco because there are quirks mode diffs
<tantek> fremy: ... apparently ...
<tantek> (horns)
<tantek> TabAtkins: what about the 2nd case? where element is an inline table?
<dbaron> The Gecko code is at https://searchfox.org/mozilla-central/rev/b318c7dca7392bd16c0b11929f55b1be133f0b31/layout/generic/nsTextFrame.cpp#5373
<tantek> TabAtkins: (describes bug)
<tantek> fremy: I see what you mean
<tantek> TabAtkins: our impl is inconsistent
<tantek> TabAtkins: the fact that these two cases should be identical in any sensible interpretation implies that it should be a box tree concept possibly with some nods to the element tree e.g. block that splits inline
<tantek> fremy: i don't know either we would have to change something either way
<tantek> astearns: sounds like we need to spec this as box-tree concept and file bugs on browsers
<tantek> TabAtkins: chrome has a bug filed
<tantek> astearns: any obj to defining this as a box-tree concept?
<tantek> RESOLVED: define this as a box-tree concept
<tantek> astearns: few more min
fantasai commentedon Jul 5, 2017
Fixed in a9a8bdd