1466564 - Nested text-decoration is inconsistent with other browsers

Status: NEW

(Core :: Layout: Text and Fonts, defect, P3)

Description

[jonmclaren1]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36

Steps to reproduce:

https://codepen.io/thewebtech/pen/ZRQNmy?editors=1100

<div class="wrapper-element underline-red"><h2 class="underline-pink">in <span class="blue-underline">firefox</span> the text other than the word firefox doesn't always have an underline</h2></div>

<div class="wrapper-element"><h2>in <span class="no-triple">firefox</span> this text has double underline but should only have 1</h2></div>

<div class="wrapper-element"><h2><span class="triple-using-line-through">in firefox this text has a triple underline but should only have 1</span></h2></div>


CSS
h2{
  text-decoration:underline; 
  font-size:70px;
  
}
.underline-pink{text-decoration-color:pink;}
.wrapper-element{
  text-decoration:underline;
}
.underline-red{  
  text-decoration:red;
}
.blue-underline{text-decoration:underline;
  text-decoration-color:blue;
}

.no-triple{text-decoration:underline;}
.triple-using-line-through{
  text-decoration-line: line-through;
 
}


Actual results:

having elements with text-decoration:underline; inside of elements with text-decoration:underline; causes double underline.

Also underline colors sometimes don't render if there are multiple selectors targeting the element.

changing text-decoration-line on an element that already has double underlines causes triple lines.



Expected results:

Only 1 underline should appear.

Comment 1

[jonmclaren1]

Screenshot of odd behavior in the linked codepen.
https://spin.d.pr/iHRZJS+

Also updating expected Results: aside from multiple underlines showing. I would expect that the cascading effects of Css would be properly honored where for example if you change the text-decoration-line to a different setting, it would have priority, not just move a new underline.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Yeah, there's definitely something wrong there, since as soon as you open the devtools window, which causes a reframe, the strike-through appears...

Any chance you could figure out whether this is a regression using:  https://mozilla.github.io/mozregression/quickstart.html?

Thanks!

Comment 3

[jonmclaren1]

I don't have pip (on mac) and don't care to install it just for this, otherwise I'd give it a go. Sorry.

Comment 4

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=50a3378c5940&tochange=5edb33c72ec0

Suspect: Bug 223764 and Bug 403524

Comment 5

[Emilio Cobos Álvarez (:emilio)]

(In reply to Alice0775 White from comment #4)
> Regression window:
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=50a3378c5940&tochange=5edb33c72ec0
> 
> Suspect: Bug 223764 and Bug 403524

Thanks a lot Alice! Sorry I missed your comment before.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Actually I think Firefox is correct on this one (modulo the inconsistent underline which is probably a paint invalidation issue).

Text decorations are reset properties per spec (they don't inherit) though WebKit-based browsers implement it as an inherited property. Jon, can you link to the spec you were referring to?

In particular, https://drafts.csswg.org/css-text-decor/#text-decoration-line-property says:

> Specifies what line decorations, if any, are added to the element. Values have the following meanings:
>
> none Neither produces nor inhibits text decoration. 

So note that once you specify a text decoration, there's no way to inhibit it under it.

Similarly:

> The color of text decorations must remain the same on all decorations originating from a given element, even if descendant boxes have different specified colors.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

See also https://bugs.chromium.org/p/chromium/issues/detail?id=553174 which is the bug tracking the incorrect propagation for Blink, and bug 1222703 which has more context.

Comment 8

[jonmclaren1]

> The color of text decorations must remain the same on all decorations originating from a given element, even if descendant boxes have different specified colors.

Firefox is disobeying this exact rule you're talking about. I've updated the codepen linked above as your pointing out this statement caused me to find another related issue. See the second sentence. 

Based on the statement from the spec that you quoted, the text decoration should not become line-through, and should not be a different color. There also should not be two text decorations happening.

It also doesn't explain the double and triple underlines we're seeing. If it were being treated as a reset property these wouldn't be possible.

> none Neither produces nor inhibits text decoration. 

I'm not sure if you were understanding the issue, this issue happens when you DO NOT use "none"(see codepen)

Sorry if I muddied things up by not separating this into multiple separate issues. I thought they were all likely part of the same core problem.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Ok, let's grab the simpler example:

<style>
div {
  text-decoration: underline purple;
}

h2 {
  text-decoration: underline blue;
  font-size:70px;
}
</style>
<div><h2>Should have two different underlines</h2></div>

Per spec, there are two elements generating text-decorations here, the <div> and the <h2>. The <div> generates a purple underline text decoration, and the <h2> generates a blue underline text decoration. This is what Firefox does, and looks correct given my reading of the spec. text-decorations aren't inherited. Did I get that wrong?