text-decoration: none not honored for inline elements inside an anchor

RESOLVED INVALID

Status

()

RESOLVED INVALID
16 years ago
16 years ago

People

(Reporter: ssmith, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/20030612 Camino/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/20030612 Camino/0.7+

In the code at http://iavidev.forumone.com/anchor.html which I've tested in Mac
Mozilla, Windows Firebird, and Mac Camino, when an inline element, such as a
span tag, is placed inside an anchor whose style is set to text-decoration:
underline, the span tag's text-decoration: none is ignored. Interestingly, the
opposite is not true. If "a" is set to text-decoration: none and the span is set
to text-decoration: underline, the problem does not appear. Also interestingly,
KHTML (via Safari) has the same bug, but Mac IE 5.x and Windows IE 6 do not.

Reproducible: Always

Steps to Reproduce:
1. Define an anchor "a" tag with text-decoration: underline in CSS
2. Define a class with text-decoration: none in CSS
3. Place text like so: <a href="#"><span class="noUnderline">Not
underlined,</span> underlined.</a>


Actual Results:  
All text will appear underlined, though inheritance rules say it should not.

Expected Results:  
Text inside the span should NOT have been underlined, while leaving the rest of
the text inside the anchor underlined.
invalid. this is how text-decoration works.

If you make the inner span have a slight vertical-align: 0.2em; for example, and
then give it an underline, you'll see that both elements get underlined. When
you set the inner one to 'none', you are turning off the inner underline. It
doesn't affect the outer one.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID

Comment 2

16 years ago
I don't understand the resolution.  It makes sense when talking about block
level elements, but shouldn't inline elements let you mark up the element
itself, rather than just putting a new layer of markup over it?  Is there any
way to directly address a portion of the text contained in the anchor?
(Reporter)

Comment 3

16 years ago
I'm not sure I understand why Gecko would want to do things that way. To my
mind, inline elements affect that which is inside of them, not functioning as
block-level elements that happen to be on a line. That is, if you apply one
style to text, such as text-decoration (since it's not called
element-decoration, I expect it to be applied to text rather than spans), and
then override that style, it should be overridden in all cases.

So to my mind there should NOT be two underlines, and if you apply a .2em
vertical-align, the underline should jump up with that text, rather than reveal
a duplicate underline.

If there are advantages to treating inline styles as blank slates every time,
I'd like to hear them, but at present I don't understand why that sort of
inheritance should apply to inline as opposed to block-level elements.

If this has been hashed out before, I humbly beg forgiveness, and just chalk it
up to one more counter-intuitive thing I hate about CSS. For the practical
upshot is that you CANNOT leave the default as underlined and de-underline a
portion of a link--that forces me to split it into two links, which bleeds my
presentation over into my document structure, and will inconvenience disabled
users who have to hear redundant "LINK: " statements in their readers.
CSS currently has no way to interrupt underlines for parts of elements, it's
just an all or nothing deal at the moment. This is a known limitation, which
will probably be addressed in CSS4.

The CSS model does make more sense, just think about underlining things like:

   <p> The 1<sup>st</sup> Avenue Restaurant. </p>

For a discussion of how text-decoration works, see:
   http://www.w3.org/TR/css3-text/#text-decoration-overview
(Reporter)

Comment 5

16 years ago
Ah, enlightenment--thanks.
You need to log in before you can comment on or make changes to this bug.