Closed Bug 24173 Opened 25 years ago Closed 25 years ago

SPAN tag nested in A(nchor) tag causes anchor to fail

Categories

(Core :: CSS Parsing and Computation, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED INVALID

People

(Reporter: dciemo, Assigned: attinasi)

References

()

Details

Attachments

(4 files)

Mozilla M12, Win32 Version, Downloaded 1/17/2000. A <SPAN> tag nested in an <A> tag like so will cause the anchor to fail to render in the SPAN style and will fail to be active: <A HREF="url"><SPAN STYLE="COLOR:7F0000>Link Text</SPAN></A> See attached URL for better test case which illustrates expected behavior. I discovered this bug browsing http://clubs.excite.com/ Excite uses <span> to change the color of the anchors in the upper left hand corner navigation once you've logged in to a specific club: My Clubs Clubs Directory Welcome Announcements My Messages ...
Attached file Test case (deleted) —
QA Contact: chrisd → petersen
I don't see the bug with recent builds on Mac and Windows. Marking WorksForMe.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Agreed. I not able to reproduce this problem on the 200012008 build.
Status: RESOLVED → VERIFIED
I've reopened this bug partially resolved, rather than opening a new bug. Yes, the anchor works now in Build ID 20000121116, January 21, 18:47PST. **HOWEVER**, the underline is BLUE, not the same color as the font. The anchor underline should be the same color as the font. Unless the tester / implementor is color-blind or changes the default LINK color in their browser, it should have been obvious that the expected result and actual result were not identitical. If need be, I'll submit a new bug.
Status: VERIFIED → REOPENED
I'm not color-blind but I thought that the <font> tag was inheriting the 'text- decoration' attribute while the span had the default 'text-decoration' which is 'none', and that all of this was just fine. Maybe it's not so I'm running it through Troy to get a second opinion.
Resolution: WORKSFORME → ---
Really re-assigning it to Troy to get his opinion.
Assignee: pierre → troy
Status: REOPENED → NEW
Attached file simpler testcase (deleted) —
Looking the test case marked "simpler testcase", I don't see why there should be an underline color difference between the first case (FONT inside of a A tag) and the second case (SPAN inside of a A tag). Yes, 'text-decoration' has a default value of 'none', but that's true in both cases. I see the text inside of the nested tag (FONT or SPAN) underlined in both cases, but in case one it's red (like it should be) and in case two it's blue The overriding issue is that they're part of the link and hence the :link pseudo-class rules defined in html.css apply: :link { color: blue; text-decoration: underline; cursor: pointer; } That's why they are underlined in both cases. As dciemo@excite.com points out, I don't know why the underline color is wrong in the second case Pierre, I'm assuming this is a style issue and re-assigning back to you. If you think it's a problem in the block/inline code, then re-assign to Kipp's bug list
Assignee: troy → pierre
Sorry for the color blind quip. I've been rail-roaded by Netscape as a vendor over the past 5 years when I've spent time and effort putting together test cases that demonstrate real (if not quite mainstream) problems. I appreciate the fact that Mozilla.org has an open bug system. I've gotten better responses to issues in the past week then I'd gotten over the past 5 years. Thanks.
I think Troy was wrong on this one. In my opinion, the second case (span with blue underline) is correct and the question for me is to know why the <font> tag inherits the text-decoration from its parent. The second case is correct because that's the way 'text-decoration' works. The attribute from a parent is propagated through its children. See test0.html. The spec says "This property is not inherited, but descendant boxes of a block box should be formatted with the same decoration (e.g., they should all be underlined). The color of decorations should remain the same even if descendant elements have different 'color' values." See http://www.w3.org/TR/REC-CSS2/text.html#propdef-text-decoration for more info. Reassigned to the New Guy(tm): Marc Attinasi.
Assignee: pierre → attinasi
See bug 7120, bug 11377 and bug 20102 for more info. It really confirms what I was saying: the blue underline is correct. The question is: why does the <font> tag changes the underline to red? It doesn't not have a "text-decoration: underline" rule so it should not affect the underline from the parent. I think I remember having seen when dumping the style contexts that the one corresponding to the <font> tag had the text-decoration set to 'inherit'. If it's true, why?
Okay, after having reread the spec several times, I can see how it may be the case that the underline should be blue. And the fact that both MSIE 5.0 and NS 4.61 both get it wrong doesn't surprise me. However, this now begs the question: how does one set the text decoration color so that both text and underline are the same (or different) colors? Is this a hole in the CSS2 spec? For completeness, if the underline is not going to inherit the color, then there must be a way of specifying a text underline (or strikethru or ...) color. This could be cool for providing red strikethrus through black text for instance. Since <font> has no way of specifying a separate decoration color (does it?) and both MSIE and NS change the decoration along with the foreground color, then does it make sense to leave <font> behavior as is?
If you add "text-decoration:underline" to the style attached to the span, the underline will be displayed red (or whatever the color of the span is). The thing you cannot do is remove the underline because it has been set in the parent block.
The <font> tag inherits the text-decorations (line 336 of nsHTMLFontElement.cpp). The reason behind that behavior is compatibility with older documents that set text attributes through HTML tags like <U> or <FONT>. All is well: <font> inherits the text-decorations, <span> and other elements don't. In one case the underline becomes red, in all the other cases it stays blue unless you specify "text-decoration:inherit". As David Baron wrote in bug 20102, I can't say I like it but the spec is the spec and I'm closing this bug as Invalid.
Status: NEW → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → INVALID
QA Contact: petersen → chrisd
Testcases rendering correctly. Verifying bug invalid.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: