Closed Bug 1222703 Opened 4 years ago Closed 4 years ago

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

Categories

(Core :: Layout: Tables, defect)

defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: matma.rex, Unassigned)

Details

Attachments

(1 file)

144 bytes, text/html
Details
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).
Component: Untriaged → Layout: Tables
Product: Firefox → Core
Attached file testcase
Attachment #8684673 - Attachment description: xxx.html → testcase
Version: 43 Branch → Trunk
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?
Flags: needinfo?(dbaron)
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
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.
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.)
Flags: needinfo?(dbaron)
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.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
Fascinating. Thank you for the quick responses!
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?
@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 9 is spot on.  Blink is treating propagation as being like inheritance, and it's just not.
You need to log in before you can comment on or make changes to this bug.