Bug 23804 – text-decoration:none inside an anchor tag doesn't match IE (i.e. remove underlines)

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Layout and Rendering

[Jeremy Moskovich]

Go to http://www.limat.co.il/Heb/AboutTheCompany.aspx  and look at the text in the yellow box on the right.

The text has text-decoration:none specified in it's css, however it's displayed with an underline, see attached screenshot.

FF3 & IE7 both display this without an underline.
Safari 3.2.1 & WebKit ToT both display an underline.

[Jeremy Moskovich]

Created attachment 27428 [details]
Screenshot

[Mark Rowe (bdash)]

The text decoration is set to underline on the <a> element that contains the <div> that has text decoration set to none.

[Jeremy Moskovich]

Created attachment 27454 [details]
Reduction

[Andras Nemeseri]

This is not a bug in webkit:
The spec said (css 2.1, text): " ... When specified on an inline element, it affects all the boxes generated by that element; ... The 'text-decoration' property on descendant elements cannot have any effect on the decoration of the ancestor."
(http://www.w3.org/TR/CSS21/text.html#lining-striking-props)

IE8 and Opera renders the underline correctly. I have filed a bugreport to fix this problem in firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=478505


Please note that you should not insert a <div> inside an <a>, because it's invalid HTML.

[Jeremy Moskovich]

It looks like in standards mode at least, WebKit is the one doing the right thing here, the relevant Mozilla bug (courtesy of Hixie):
https://bugzilla.mozilla.org/show_bug.cgi?id=491670

[Ojan Vafai]

It seems to me that matching FF is the most important thing here. According to the Mozilla bug, it sounds like they might be considering changing their behavior to be more like WebKit's current behavior (which, according to the Mozilla bug, seems to match the CSS2.1 spec).

Hixie, Hyatt do either of you have strong opinions here as to whether we should try to match the spec vs. what sites currently expect (at least this one site does anyways).

[Ojan Vafai]

See below for details. The Firefox behavior is clearly just a bug that should be fixed in Gecko. We might want to consider mimicking the IE behavior for text-decoration in an anchor tag since sites seem to depend on it.

Some other sites that have this problem (i.e. WebKit has underlines, but IE/FF do not):
-Links in the middle column: http://www.aib.gov.uk/
-Links in the middle column: http://www.aramark.co.uk/
-"Community" link: http://www.askamum.co.uk/
-The house listings: http://www.bflhomes.co.uk/
-The "tg" in the navbar on the left: http://homeshopping.24studio.co.uk/fashion/womens/by-brand/tg/12/maxidressbytg/1/?source=TL80&cm_mmc=Google%20Base-_-tg-_-Shopping%20Feed-_-Maxi%20Dress%20By%20TG

To test this, I tried the following HTML in FF, IE, Safari:
<a href="foo">
    <div style="text-decoration: none;">foo</div>
    <span style="text-decoration: none;">foo</span>
</a>
<span style="text-decoration:underline;">
    <div style="text-decoration: none;">bar</div>
    <span style="text-decoration: none;">bar</span>
</span>

-WebKit: underlines the contents of both the span and the anchor tags in quirks and standards modes.
-Firefox: underlines them both in quirks mode, but doesn't underline the contents of either div in standards mode.
-IE: underlines the contents of span, but not the contents of the anchor tag in both quirks and standards modes.

Note that IE renders the following with a line-through, but no underline:
<a href="foo" style="text-decoration:line-through">
    <span style="text-decoration: none;">foo</span>
</a>

[JoeJava]

This webpage is for a firefox bug that covers the same issue, and shows the behavior of several web-browsers (Firefox, Opera, Internet Explorer, Safari, and Amaya)

https://eyeasme.com/Joe/Firefox_bug.html

[Jeremy Moskovich]

Firefox has been updated to match WebKit's behavior here - see https://bugzilla.mozilla.org/show_bug.cgi?id=491670 .

Should I close this bug?

[Ojan Vafai]

Since Gecko and WebKit match now, I'm less inclined to implement this IE quirk. Hopefully the number of sites that depend on this quirk will decrease from now on and the web won't need to support this forever.