169078 - .class:hover should be ignored for non-links in quirks mode

Status: VERIFIED FIXED

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

Description

[[e-mail] (gone - use [e-mail] instead)]

Build ID: 2002-09-16-08, All OSs.

Summary: On http://search.netscape.com/nscp_index.adp, all of the sub-categories  

Steps to Reproduce:

1. Load http://search.netscape.com/nscp_index.adp.
2. Mouseover any element under a bolded heading (eg. 'Video Games' under 'Games'
category).

Expected Results:

In NS 7.0 RTM and Opera/IE 6 for Windows, this is correct (each element gets
TEXT-DECORATION: underline applied on :hover)

Actual Results:

Using the trunk Mozilla/Netscape 7.x builds, we apply TEXT-DECORATION: underline
to all of the elements when you're only mousing over one.

From http://search.netscape.com/search.css, here are the style rules:

.odpcat {FONT: 12px arial,geneva; TEXT-DECORATION: none}
.odpcat:hover {TEXT-DECORATION: underline}

Here are the table elements:

<td class=odpcat width=25%>
										<a href="nscp_browse.adp?gn=gwd/Top/Arts&source=NSCPIndex"
class=size2b>Arts</a><br>								&nbsp;<a
href="nscp_browse.adp?gn=gwd/Top/Arts/Movies&source=NSCPIndex"
class=odpcat>Movies</a><br>
&nbsp;<a href="nscp_browse.adp?gn=gwd/Top/Arts/Television&source=NSCPIndex"
class=odpcat>Television</a><br>
&nbsp;<a href="nscp_browse.adp?gn=gwd/Top/Arts/Music&source=NSCPIndex"
class=odpcat>Music</a><br>
									</td>

Comment 1

[Doron Rosenberg (IBM)]

Eric - regression or css coding issue?

Comment 2

[Eric A. Meyer (dead account)]

Coding issue.  The rules should be:

a.odpcat {FONT: 12px arial,geneva; TEXT-DECORATION: none}
a.odpcat:hover {TEXT-DECORATION: underline}

...or else:

.odpcat a {FONT: 12px arial,geneva; TEXT-DECORATION: none}
.odpcat a:hover {TEXT-DECORATION: underline}

As written, the hover styles are being applied to the 'td' cell (since it has a
class of 'odpcat'), and thus getting pixked up by the entire content of the
cell.  This is another case of "hover applies to more than links" surprising a
designer.  I have an action item to write a DevEdge piece on the topic.

Comment 3

[Susie Wyshak]

I don't see this in a 11/4 branch build (rv:1.0.2). Eric do you have an old
branch you can try this on?

Comment 4

[Eric A. Meyer (dead account)]

All my back versions are trunk builds.  My Windows version of Netscape 7.01
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120]
doesn't show the reported behavior, but trunk builds from before 11/20 do.

I still believe this to be a site-design error, because the text is content of
the 'td' element and so should be affected by 'text-decoration' changes to their
parent.  However, I'm cc:ing David Baron and Ian Hickson on this in case I'm
wrong about how text decoration is supposed to be applied to inline elements of
a 'table-cell' element, and this is a bug after all.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I suspect the change that triggered this was a change to our :hover behavior --
allowing hover to apply to non-links in more cases (we have some quirks to
prevent :hover from applying to non-links in quirks mode).  I weakened them with
the fix to bug 96984, and I'm hesitant to readd quirks just for one site that
could, one hopes, be easily convinced to change (perhaps with a change as small
as changing ".odpcat:hover" to "a.odpcat:hover").

Comment 6

[Susie Wyshak]

This works for me on 11/20 branch (Netscape 7.01). 

Comment 7

[Eric A. Meyer (dead account)]

Given the number of sites (small but noticeable) that will have one of the
following two:

  :hover {color: red;}
  .class:hover {color: red;}

...it would make a lot of sense to change quirks mode so that selectors of the
above two forms are applied only to hyperlinks.  In other words, a hover
selector by itself, or in conjunction with a class value but no element, should
not be applied to non-links.  In standards mode and almost-standards we should
continue applying :hover to everything, of course.

I'd like to formally request this behavior, so where would you prefer it go-- a
reopened 96984, a new bug, or right here?

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

We already have a quirk for the former, and if you want one for the latter,
reassigning this bug seems fine.

Comment 9

[Eric A. Meyer (dead account)]

Per comment 8, reassigning bug and changing summary.  See comment 7 for the
proposed change in quirks mode.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Really reassigning.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 111503 [details] [diff] [review]
patch

yeah.... we have far too many evang bugs on this issue...

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to trunk, 2003-01-14 13:50 PDT.

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 189507 has been marked as a duplicate of this bug. ***

Comment 15

[Sander]

*** Bug 191772 has been marked as a duplicate of this bug. ***

Comment 16

[guanxi]

*** Bug 159720 has been marked as a duplicate of this bug. ***

Comment 17

[Boris Zbarsky [:bzbarsky]]

*** Bug 192678 has been marked as a duplicate of this bug. ***

Comment 18

[Madhur Bhatia]

verified on linux trunk build 2002-02-17-05

Comment 19

[[e-mail] (gone - use [e-mail] instead)]

...mac, win32?

Comment 20

[djk]

A bug was just filed which seems like it should have been taken care of by this
bug (at least from the description of this bug).

Bug 199584 notes a page in quirks mode which uses .class:hover.  The :hover
style is still being applied to things like textareas and submit buttons.