149704 - abcnews.go.com - a:hover highlights <a name="foo">

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[Keith Hankin]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0+)
Gecko/20020531
BuildID:    2002053104

Paragraph text gets highlighted (turns to light blue from dark blue) when doing
a mouse-over on any text in the article below the section titled "A Parent's
Plea".  This problem does not occur for text above this section.
This problem does not occur with IE.

Reproducible: Always
Steps to Reproduce:
1.Go to URL http://abcnews.go.com/sections/us/DailyNews/missingutahgirl020606.html
2.Mouse-over text in section titled "A Parent's Plea".
3.

Comment 1

[Boris 'pi' Piwinger]

Yes, it is happening. I cannot see a reason in the sources. I think, there is
already a bug on this.

pi

Comment 2

[Sitsofe Wheeler]

It's an HTML/CSS error by whoever authored the page - there is an open <A NAME>
that hasn't been closed. I'm not going to wade to the javascript to find exactly
which css file the rules are in but I bet there is an a:hover rule somewhere (so
anchored links in addition to hrefs are going to glow).

Comment 3

[Keith Hankin]

It may be a bug in the page, but Netscape and IE both deal with it reasonably. 
Can't Mozilla do the same?

Comment 4

[Sitsofe Wheeler]

(Changing platform and OS to all and putting severity down to trivial)

I presume when you say that it works with Netscape you are refering to Netscape
4 (you didn't say which version)?

My gut feeling is to say "Ask abcnews to fix their site" since their HTML is
definitely incorrect (and they close their earlier tags so why suddenly stop
half way through?).

This error shows up because Mozilla really does follow the standards -
http://www.w3.org/TR/html4/index/elements.html (the end tag on an A element is
NOT optional). I suspect you could debate whether <a name> should match a: css
rules (in Opera it doesn't) when working in quirks mode but I'm sure this has
been discussed elsewhere.

Comment 5

[Boris 'pi' Piwinger]

Sitsofe,

could you really track it down to text between <a name=...> and </a> following
hover styles? If so we have several bugs on this, all marked as INVALID.

pi

Comment 6

[Sitsofe Wheeler]

Find the following line

<p><a name=1><span class="subhead">A Parent&#146;s Plea</span><p>

Notice how there isn't a </a> until
<div align="center"><a class="blackLargeLink"
href="http://printerfriendly.abcnews.com/printerfriendly/Print?fetchFromGLUE=true&GLUEService=ABCNewsCom"><img
src="http://media.abcnews.com/media/Sports/images/content_printer_icon.gif"
width="18" height="13" valign="absmiddle" border="0"> PRINT THIS
PAGE</a>&nbsp;&nbsp;<font color="#666666">|</font>&nbsp;&nbsp;

And http://i.abcnews.com/css2/ABC_default.css starts with
A:hover { color:#3196FE; }

I recommend that someone should contact abcnews and point out the error in their
html (including a link to this bug) so that this can be fixed at their end.

Comment 7

[Boris 'pi' Piwinger]

Over to Evangelism.

pi

Comment 8

[Keith Hankin]

Yes, it works fine with netscape 4.7 but not with Mozilla.

Comment 9

[Keith Hankin]

Why is this an issue for evangelism?  Considering that netscape 4.7 and IE both
manage to render this correctly and figure out what the user really meant, why
can't mozilla do the same?  Besides, abcnews might fix it for this page, but
then the same error will occur somewhere else and the problem will crop up
again.  It seems that mozilla should be forgiving with regards to markup errors
so that it can render more pages correctly.  Yes, people shouldn't be releasing
invalid html, but it does happen in the real world, and very often.

Comment 10

[Boris 'pi' Piwinger]

Keith,

see bug 54318, bug 143676, bug 148129. We can dupe on those or as the broken
site to fix it.

pi

Comment 11

[Sitsofe Wheeler]

Keith, what you are proposing is potential bad behaviour and saying "Everyone
else does it" may not get very far. I just want to reiterate, this is not a bug
in Moz (really - Moz is not doing anything *wrong*) so unless someone is going
to provide clean code for a workaround and then fight with all the people who
will resist it (and I'm pretty certain there would be resistance) this is
unlikely to be fixed. There are only so many kludges and workaround that you can
put in until you end up with a mess (both in code and eventually output) - look
at NS 4.

What CAN be fixed easily and quickly is the HTML and CSS on broken pages (thanks
for pointing this one out). This looks like some sort of accident and often
people don't know that there is a problem until is pointed out to them. The
fix(es) (there are two things that will make this go away and ideally you should
do both) will not be detrimental to other browsers and may even help them to
parse it properly and/or fix other subtle problems that may have been on the
page. Thus I feel that asking the page to be fixed is both the best thing
technically and in terms of effort.

Comment 12

[Keith Hankin]

I agree that Mozilla isn't doing anything wrong here.  But one of the main
reasons that will keep Mozilla from gaining market share is if it can't display
web pages as they were intended to be displayed as well as IE.  Yes, people
should take care to make sure they fix their pages before publishing them, but
in the real world, this often does not happen.  The result is that it APPEARS as
if Mozilla is broken, since the pages display fine in other browsers which are
more forgiving of mistakes.  And the final result is that fewer people people
will use Mozilla.

Comment 13

[Samir Gehani]

-> default owner

Comment 14

[Warren Hedley]

Attachment: demo of a:hover behaviour with anchors and hyperlinks

I had a few additional comments, which are supported by the attached file,
namely that IE's behaviour is actually what developers want in the case of the
a:hover rule. If I define a set of rules for hyperlinks using the CSS specified
in section 5.11.3 of the CSS 2 spec (
http://www.w3.org/TR/REC-CSS2/selector.html#dynamic-pseudo-classes ), then
chances are the I don't want the hover behaviour to actually apply to <a>
elements that are acting as anchors rather than hyperlinks (i.e., they don't
define an @href attribute). Variants on this are shown in the first two rows of
the table in the attached file. IE6 ignores the :hover rule for the anchor
elements.

The third row combines the :link and :hover pseudoclasses and both mozilla and
IE6 ignore the :hover rule for the anchors. However, I suspect the majority of
CSS stylesheets out there that define a:hover rules don't define them as
a:link:hover.

In summary: although not strictly conforming, IE's behaviour is perhaps
slightly more intuitive.

Comment 15

[Christopher Hoess (gone)]

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

Comment 16

[Christopher Hoess (gone)]

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

Comment 17

[Bob Clary [:bc] (inactive)]

tech evang june 2003 reorg

Comment 18

[Nick Kaijaks]

Observe same effect with valid XHTML markup too - <a name="foo" /> causes
following text to have hover rule applied. Maybe more than evangelism required?

Comment 19

[Matthias Versen [:Matti]]

404