1222703 - Firefox does not propagate 'text-decoration' to children with 'display: table-cell' (without wrapping table, table-row)

Status: RESOLVED INVALID

(Core :: Layout: Tables, defect)

Description

[Bartosz Dziewoński]

User Agent: Opera/9.80 (Windows NT 6.1; WOW64) Presto/2.12.388 Version/12.17

Steps to reproduce:

Firefox does not propagate 'text-decoration' to children with 'display: table-cell' (without wrapping table, table-row).

Test case: (http://jsfiddle.net/7k758v7L/)

.a { text-decoration: underline; }
.b { display: table-cell; }
<span class="a"><span class="b">Underlined?</span></span>




Actual results:

The text is not underlined.


Expected results:

The text should be underlined. All other browsers I tested behave this way (Chromium 46, IE 11, Opera 12), and it seems to be what http://www.w3.org/TR/css-text-decor-3/#line-decoration says should happen (although it's very jargon-heavy and I might've misunderstood).

Comment 1

[j.j.]

Attachment: testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

So per spec, I would think the behavior of that testcase should be exactly the same as the behavior of this testcase:

  .a { text-decoration: underline; }
  .b { display: inline-table; }
  <span class="a"><span class="b">Underlined?</span></span>

or

  .a { text-decoration: underline; }
  .b { display: table-row; }
  <span class="a"><span class="b">Underlined?</span></span>

because they produce exactly the same box structure.  You can see the latter two testcases at http://jsfiddle.net/7k758v7L/1/ and http://jsfiddle.net/7k758v7L/2/ and the first one doesn't get underlining in Chrome while the second one does.

IE Edge has the same behavior as Chrome, looks like.

As far as I can tell, that's just a bug in IE and Chrome.  David, you're more familiar with the text-decoration stuff; do you see anything in the spec there that would cause the above identical box structures to have different text-decoration behavior per spec?

Comment 3

[Boris Zbarsky [:bzbarsky]]

And in particular, the relevant thing that makes all the box structures the same is http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes

Comment 4

[Boris Zbarsky [:bzbarsky]]

Oh, and looking at the Blink code for this, they have this comment in StyleAdjuster.cpp:

// CSS requires text-decoration to be reset at each DOM element for
// inline blocks, inline tables, shadow DOM crossings, floating elements,
// and absolute or relatively positioned elements. Outermost <svg> roots are
// considered to be atomic inline-level.

but CSS doesn't say anything about text-decoration being reset at each DOM element.  It talks about propagating, or not, the decoration to child _boxes_ (per the spec link from comment 0).  In this case, that would be propagating from the outer <span>'s inline to the anonymous inline-table box, which the spec says should not happen, afaict.  So the problem is just that Blink has a model of decorations which totally doesn't match the spec.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I don't know of anything that should make those different.

(And I think https://drafts.csswg.org/css2/tables.html#anonymous-boxes and https://drafts.csswg.org/css-text-decor/#line-decoration should basically match each other, modulo the latter having additional rules for ruby, and the former not quite being consistent about element vs. box terminology... though being loose about that is a generally accepted deficiency of CSS level 2, and shouldn't be interpreted to actually mean element when it ought to mean box.)

(One other thing I wonder is whether both IE and Chrome are good about creating an inline-table rather than a table.)

Comment 6

[Boris Zbarsky [:bzbarsky]]

IE and Chrome do create an inline table in this situation; WebKit fixed that a while back.  The problem at least in Blink is they compute text-decoration on the element tree instead of propagating on the box tree, as far as I can tell.

Marking invalid.  I've filed https://code.google.com/p/chromium/issues/detail?id=553174 on Blink.

Comment 7

[Bartosz Dziewoński]

Fascinating. Thank you for the quick responses!

Comment 8

[dgrogan (chrome)]

Boris, your analysis seems to imply that inheritance happens after the box structure is filled in with a table's anonymous boxes via https://drafts.csswg.org/css2/tables.html#anonymous-boxes. How do you reconcile that with https://drafts.csswg.org/css-cascade-3/#inheriting, which has "Note: Inheritance follows the document tree and is not intercepted by anonymous boxes"?

That section (https://drafts.csswg.org/css-cascade-3/#inheriting) suggests that in the example from comment 0, "text-decoration: underline" could only propagate from the outer span directly to the table-cell, ignoring any anonymous table objects.

If our reading is correct, we'd follow the prose in the first paragraph of https://drafts.csswg.org/css-text-decor-3/#line-decoration and say that a box with display:table-cell is not an inline box, nor is it a block container that establishes an inline formatting context, nor is it a ruby box, so it qualifies for the catch-all: "For all other box types, the decorations are propagated to all in-flow children."

(Note that such reading would bypass the question of whether Blink properly creates an inline-table rather than a table -- which it does not: https://crbug.com/327832.)

If our reading is incorrect could you explain what we missed?

Comment 9

[Rune Lillesveen]

@dgrogan: Propagation is not inheritance. IIUC we do propagation in Blink at computed style time using a synthesized property for propagated text-decoration, which won't work with anonymous boxes as they are inserted after the style has been computed.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Comment 9 is spot on.  Blink is treating propagation as being like inheritance, and it's just not.