278879 - <li> elements don't respect text-decoration property

Status: RESOLVED DUPLICATE of bug 10458

(Core :: Layout, defect)

Description

[Benjamin Lebsanft]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050117 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050117 Firefox/1.0+

HTML Code:

<span class="linkd">
<ul>
<li> Oberbegriff
<ul>
<li>unterbegriff</li>
<li>2.unterbegriff</li>
</ul>
</li>
</ul>
</span>

CSS:

.linkd a {
font-family: "helvetica";
color: #000;
font-size: 110%;
text-decoration: none;
letter-spacing:1px;
}

.linkd ul {
border: 1px dashed #ddd;
margin-left:0px;
padding-left:10px;
}

.linkd ul li {

text-decoration:underline;
list-style-type: none;
}

.linkd ul li ul {
border-style:none;
margin-top: 5px;
padding-left:25px;
text-decoration:none;
}

.linkd ul li ul li {
list-style-type: square;
text-decoration:none;
}

.linkd {
margin-bottom:15px;
margin-top:15px;
margin-left:0px;
text-align:left;
}

the text-decoration on the second li elements have no effect, even if !important
is used. This happens in FX 1.0 and my current version. I am reporting this bug
for someone from the computerbase forum:
http://www.computerbase.de/forum/showthread.php?t=110182

We don't know if this is a bug or an error in css, but i can't find one. Even
when assigning classes the text-decoration property has no effect!

Reproducible: Always



Expected Results:  
don't underline the li elements

Comment 1

[Mats Palmgren (inactive)]

Attachment: Reporter's testcase

WFM, Mozilla 2005-01-17-05 trunk Linux.

Comment 2

[Benjamin Lebsanft]

(In reply to comment #1)
> Created an attachment (id=171709) [edit]
> Reporter's testcase
> 
> WFM, Mozilla 2005-01-17-05 trunk Linux.

strange, using Firefox 2005-01-18 trunk Linux it still underlines the <li> elements

Comment 3

[Ben Fowler]

Attachment: Test case with comment

I have looked at this and I see the problem as my expectation that 
the 'text-decoration:none;' for the selector '.linkd ul li ul li' 
should "clear" the underline specified by the selector '.linkd ul li'
(as it is more specific).

I am working on the basis that this is one the rules of CSS that I do
not understand!

I don't doubt that this is working, it is merely strange.

Comment 4

[Ben Fowler]

See http://archivist.incutio.com/viewlist/css-discuss/46801 the selector
'.linkd ul li ul li' has a specificity of 104, greater than the
101 of '.linkd ul li', and Gecko seems to respect this is the case
of the properties 'color' and 'list-style-type'; so why not 'text-decoration'?

Which is what I think the OP was asking. I don't doubt that this is
a CSS issue not a Gecko one, but I would be interested in any pointers
to further information. 

Comment 5

[Ben Fowler]

See http://www.w3.org/TR/WD-css1-960505.html#text-decoration

  This property is not inherited, but children elements should 
  match their ancestor. E.g., if an element is underlined, the 
  line should span the child elements. The color of the underlining 
  will remain the same even if descendant elements have different 
  'color' values.

My attached file certainly shows these specifications at work. Is it
impossible for a child element to "clear" a text-decoration:underline?

Comment 6

[Benjamin Lebsanft]

thats exactly what I meant. The text-decoration is inherited no matter what.

Comment 7

[Ben Fowler]

(In reply to comment #5)
> ... Is it impossible for a child element to "clear" a text-decoration:underline?

That should be 'descendant element'. It is possible that using a parent-child
selector (tilde ?, greater than ?) syntax would enable the OP do do what he 
wants. Is this CSS3 only? Is it known to be not implemented in Gecko?

Comment 8

[Benjamin Lebsanft]

(In reply to comment #7)

I even tried to give the <li> - Elements specific classes, but that doesn't work
aswell. Neither does ">" work.

Comment 9

[Simon Montagu :smontagu]

I think this is a dupe of bug 10458.

Comment 10

[Ben Fowler]

See Bug Bug 258721 and Bug 10458 Comment 4 . What I am seeing looks the
same as is being described in Bug 10458. Not sure if it is an exact dup.

See (of course) http://www.hixie.ch/tests/evil/mixed/underline.html ,
underline is like that!

See Comment 1 , this behaviour is BY DESIGN and therefore this report is
INVALID.

Comment 11

[Boris Zbarsky [:bzbarsky]]

*** This bug has been marked as a duplicate of 10458 ***