Closed Bug 10458 Opened 21 years ago Closed 21 years ago

text-decoration:none not erasing underlines on hyperlinked text


(Core :: Layout, defect, P3)

Windows 98





(Reporter: koichi, Assigned: buster)




(Whiteboard: [TESTCASE])


(1 file)

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="" STYLE="text-decoration:none;">
      Go to Mozilla Homepage

However, the following code does not do so (bad case):
Code #2:
   <A HREF="">
      <SPAN STYLE="text-decoration:none;">Go to Mozilla Homepage</SPAN>

The Code #2 works perfectly well on both IE5 & NN4.6.
Assignee: troy → kipp
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
Whiteboard: [TESTCASE]
Target Milestone: M10
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>

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  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. ***
Duplicate of this bug: 554257
You need to log in before you can comment on or make changes to this bug.