Closed Bug 10458 Opened 21 years ago Closed 21 years ago
text-decoration:none not erasing underlines on hyperlinked text
I encountered this bug with M8 (and all other previous versions) using apprunner on Win98(US). This below code hides underline on the hyperlinked text (good case): Code #1: <A HREF="http://www.mozilla.org/" STYLE="text-decoration:none;"> Go to Mozilla Homepage </A> However, the following code does not do so (bad case): Code #2: <A HREF="http://www.mozilla.org/"> <SPAN STYLE="text-decoration:none;">Go to Mozilla Homepage</SPAN> </A> The Code #2 works perfectly well on both IE5 & NN4.6.
The problems seems to be that nsTextFrame::PaintTextDecorations() is checking aTextStyle.mFont->mFont.decorations to get the decorations that apply and (for whatever reason) it's set to '1'. If we checked aTextStyle.mText->mTextDecoration instead, then we would find that it's '0' like it seems it should be I don't know this code well enough to know how it should work and what nsStyleFont is used for, so I'm reassigning to Kipp
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
INVALID. Legacy browsers are wrong. See the spec; underline is not inherited, it is rendered on the entire inline box of the element with it specified, and it thus looks like the child is underlined when in fact it is simply the parent element which is spanning the child. Note. From troy's comment, I would assume that we are currently doing it slightly incorrectly: it would appear that child elements _are_ trying to underline themselves, just by using the parent's details. THIS IS WRONG. We should be simply letting the parent element draw a line just under its baseline (and in the middle and over for strike-through and overline) for all of the inline box(es). This issue is covered in bug 3488, and bug 1777. See also bug 4248.
I see. I guess I had a wrong understanding of this "inheritance". I was thinking that if someting is not inherited, that means the child span does not get the information about the same property of the parent span (in this case, the "text-decoration" property info). So if parent span has "text- decoration:line-through" and child span defines "text-decoration:underline", then the line-through at the child span is gone. But this seems to be wrong. BTW, which brings me to a new question. If I have something like, <SPAN STYLE="text-decoration:underline">Underline<BR><BR> <SPAN STYLE="text-decoration:line-through;>Line-through<BR><BR> <SPAN STYLE="text-decoration:overline">Overline<BR><BR> <SPAN STYLE="text-decoration:none">none<BR><BR> </SPAN> </SPAN> </SPAN> </SPAN> What would be the correct output? In Mozilla M8, the result is, "Underline" text has underline. "Line-through" text has underline & line-through. "Overline" text has underline, line-through, and overline. "none" text has underline, line-through, and overline. Is this the correct output? In other words, are each values of the "text- decoration" property independent of each other, except for the value "none"? My initial guess was that each text would only have underline and nothing else (no line-through and overline), but it doesn't seem to be that way.
Mozilla is correct in this example, because the underline is first applied to the first box, which contains all the others, then the second box has line- through painted on, which causes it and its children to have a line painted through the middle of them, and then the third one is overlined, along with its child. The last (innermost) box has nothing painted on, but because it is inside boxes with underlining and so on, it looks like it is underlined. See http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/underline.html for another explanation and some examples and also some areas where Mozilla gets it wrong. Look at the source code as well to see why the behaviour is expected. (If you have any queries on that page, send them directly to me by email.)
*** Bug 149973 has been marked as a duplicate of this bug. ***
*** Bug 258721 has been marked as a duplicate of this bug. ***
*** Bug 278879 has been marked as a duplicate of this bug. ***
*** Bug 310128 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.