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

RESOLVED FIXED

Status

Tech Evangelism Graveyard
English US
--
trivial
RESOLVED FIXED
16 years ago
3 years ago

People

(Reporter: Keith Hankin, Unassigned)

Tracking

({top100, top500})

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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

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

pi
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: DUPEME

Comment 2

16 years ago
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).
(Reporter)

Comment 3

16 years ago
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

16 years ago
(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.
Severity: normal → trivial
OS: Windows 2000 → All
Hardware: PC → All
Summary: Mouse-over causes inappropriate text highlighting → a:hover highlights <a name="foo">

Comment 5

16 years ago
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

16 years ago
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

16 years ago
Over to Evangelism.

pi
Component: XP Apps → US General
Product: Browser → Tech Evangelism
Version: other → unspecified
(Reporter)

Comment 8

16 years ago
Yes, it works fine with netscape 4.7 but not with Mozilla.
(Reporter)

Comment 9

16 years ago
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

16 years ago
Keith,

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

pi

Comment 11

16 years ago
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.

Updated

16 years ago
Summary: a:hover highlights <a name="foo"> → abcnews.go.com - a:hover highlights <a name="foo">
Whiteboard: DUPEME
(Reporter)

Comment 12

16 years ago
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

16 years ago
-> default owner
Assignee: sgehani → doron
QA Contact: paw → zach

Comment 14

16 years ago
Created attachment 105338 [details]
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.
Keywords: evang500
*** Bug 87372 has been marked as a duplicate of this bug. ***
*** Bug 112747 has been marked as a duplicate of this bug. ***
tech evang june 2003 reorg
Assignee: doron → english-us
QA Contact: zach → english-us

Comment 18

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

Updated

14 years ago
Keywords: top500

Updated

14 years ago
Keywords: top100
404
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.