User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090506 Shiretoko/3.5b5pre Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090506 Shiretoko/3.5b5pre See https://eyeasme.com/Joe/Firefox_bug.html Notice that the test in the box is not underlined, it should be Reproducible: Always Steps to Reproduce: 1. see https://eyeasme.com/Joe/Firefox_bug.html 2. notice that the text in the box is not underlined, it should be 3. Actual Results: Text in box is not underlined Expected Results: Text in box should be underlined See Section 16.3.1 of CSS 2.1 specification: http://www.w3.org/TR/CSS21/text.html#propdef-text-decoration See the example in this section: blockquote { text-decoration: underline; color: blue; } em { display: block; } cite { color: fuchsia; } <blockquote> <p> <span> Help, help! <em> I am under a hat! </em> <cite> —GwieF </cite> </span> </p> </blockquote> notice that the example shows the text "-Gwief" in the "cite" tag is underlined. Look at EditorOverride.css (this is a file that Firefox uses to give default CSS value to tags) (the location of this file will vary with your operating system): a:link { text-decoration: underline -moz-anchor-decoration; color: -moz-hyperlinktext; } Look at the XHTML code in https://eyeasme.com/Joe/Firefox_bug.html <a href="https://eyeasme.com/Joe/Firefox_bug.html"> <span class="box"> ... text here .. </span> </a> the CSS code for the "box" is .box { height: 250px; width: 300px; background-color: red; color: black; float: left; padding: 10px; margin-right: 25px; } Thus, following the example given in the CSS specification, I think that the text in the "box" span should be underlined. Also note that included in https://eyeasme.com/Joe/Firefox_bug.html is a table that shows how many of the latest browsers handle this example.

Referring to Comment #1 I may be wrong about EditorOverride.css being the file that sets the default CSS values. But I am somewhat sure that somewhere it is set similar to this. I could not find the default setting for the link tag in html.css file. It must be set somewhere else or hardcoded in. Once it is confirmed that the default CSS declaration for the "a" tag is "text-decoration: underline", then the argument given above should lead to the same conclusion.

The issue in this testcase is that you have a block inside of an inline, and we don't propagate text-decoration on inlines to blocks inside of them. That's correct per current CSS 2.1, as I already said in bug 491501 comment 2, but it's possible we should get the spec changed here. I think this is likely a duplicate.

Er, sorry, I'm actually wrong about what the current spec says ... thanks for pointing out that example. So we are wrong per the current spec. The key piece of the spec is the last 6 words of: # When specified on an inline element, it affects all the boxes generated by # that element; for all other elements, the decorations are propagated to an # anonymous inline box that wraps all the in-flow inline children of the # element, and to any block-level in-flow descendants. But you are wrong about EditorOverride.css. The default styles are in html.css, ua.css, and forms.css.

In Reference to Comment #3: I looked several times but could not find the default settings for the link tag "a". If someone would be so kind as to point out the file where the default behavior for the "a" tag is defined, I would be grateful. I tried looking in html.css, ua.css, and forms.css, but did not find the definition for the default values for the "a" tag specified in any of these.

You want to look for the ":-moz-any-link" or ":link, :visited" rules.

In Reference to Comment #5: I did. It appears to be in either EditorOverride.css or contenteditable.css .

See also bug 403526 (and bug 428599, bug 202930).

In Reference to Comment #7: My advise to specifications writers and API designers is: Don't do anything that surprises (i.e is non-intuitive to) the developer. This bugs behavior was surprising.

I don't see how that's related to comment 7 (which wasn't particularly directed to you).

In Reference to Comment #9: <major rant> No disrespect meant, but after reading the three bugs reports listed in Comment #7, it appears that the browser developers are asking the specifications writers about how the browsers should behave based on the standards. All three bugs are roughly waiting for the behavior to be standardized before being fixed. This is wrong. When the standards are ambiguous the developer should make a decision on behavior and move on. Specifications are written as to what is, not what is to be. The specifications will be clarified to match the behavior chosen by the developer. Some of these bugs and MANY YEARS OLD! Why should a user bother posting a bug if the developers are going to spend YEARS deciding on what they are going to do to fix it? This idea of leaving a bug open waiting for a committee to decide on a standard is wrong. Just pick a non-surprising solution and fix the bug. </major rant> So how is my comment related? Because the browser developers are waiting for the specification writers to chose a behavior for browsers to take. I am hoping they chose a non-surprising behavior. I hope this bug is fixed within this decade.

> All three bugs are roughly waiting for the behavior to be standardized before > being fixed. This is wrong. When the standards are ambiguous the developer > should make a decision on behavior and move on. We used to do that. It was disastrous, because for every ambiguity, the Firefox (then Netscape) developers made a different choice than the MSIE developers. I'm only exaggerating a little. Running all decisions of this nature through the standards body *before* implementation is how we ensure that that doesn't happen anymore.

FYI, on the WebKit side, this issue is being discussed in https://bugs.webkit.org/show_bug.cgi?id=23804

The website showing this bug has been updated to show the latest behavior of several web-browsers (Firefox, Opera, Internet Explorer, Safari, and Amaya) https://eyeasme.com/Joe/Firefox_bug.html

The website showing this bug https://eyeasme.com/Joe/Firefox_bug.html has been updated to show the latest behavior of several web-browsers (Firefox, Opera, Internet Explorer, Safari, and Amaya) latest stable Safari and Amaya are correct. latest stable Firefox, Opera, and Internet Explorer are NOT correct.

I updated the webpage at https://eyeasme.com/Joe/Firefox_bug so now it is a valid XHTML 1.0 Strict webpage. Firefox 3.6.4 is the ONLY browser to NOT underline text in a span within a hyperlink. The latest versions of the following browsers ALL correctly underline the text: Amaya, Chrome, Internet Explorer, Opera, and Safari.

Any work being done on this bug? It appears to be a pretty straight forward fix.

Updated https://eyeasme.com/Joe/Firefox_bug to show this bug. Would be nice to have fixed for FF 4.

Patch for bug 403524 causes underlines to be propagated to blocks inside inlines properly in all modes, and thereby resolves this issue.