Closed Bug 711812 Opened 13 years ago Closed 13 years ago

Linked image responds to hover in lower margin (and shows wrong cursor)

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Version:
8 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 102695

People

(Reporter: jt002, Unassigned)

Details

Attachments

(1 file)

testcase
83.48 KB, text/html
Details 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20111104165243

Steps to reproduce:

Put a margin on a linked image (and choose the "progress" cursor).

Code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv='content-type' content='text/html; charset=UTF-8'>
<title>
Margin Hover
</title>
<style type="text/css">
img {
	margin: 15px;
	cursor: progress;
}
</style>
</head>
<body>
<a href="http://www.mozilla.org"><img src="testimage.jpg"></a>
</body>
</html>



Actual results:

The link responds to a mouse hover in the lower margin, but not the upper, right, or left margins. (In addition, it displays the wrong cursor, which can't be overridden in CSS. If the margin bug weren't present, this wouldn't matter, of course).


Expected results:

The link should respond to a hover only on the image itself, not in the lower margin.
Component: General → Layout: Images
Product: Firefox → Core
QA Contact: general → layout.images
This is correct behavior given the click targets here.  When you hover the _anchor_ but not the image, you get the normal hover-the-anchor cursor.  You can put a background or border on the anchor to see the relevant rectangle.  Note that Opera has the same behavior.  WebKit does some sort of special-casing for anchors with no bacgkrounds or borders where they have a different clickable area, as far as I can tell.

> The link should respond to a hover only on the image itself

It should respond to a hover wherever clicking would trigger the link.  Where that is happens to not be defined in any specs.  Note the long discussion in bug 102695 though.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Sorry, but I just don't get it. Chrome and IE9 handle this properly. Why should clicking in one part of the image margin trigger the link, but clicking in any one of the other three parts of the margin NOT trigger the link?

I've read the "duplicate" bug thread, but that doesn't seem to be addressing the same issue at all.
(In reply to EarlyOut from comment #2)
> Sorry, but I just don't get it. Chrome and IE9 handle this properly. Why
> should clicking in one part of the image margin trigger the link, but
> clicking in any one of the other three parts of the margin NOT trigger the
> link?

Because the other three parts of the margin are outside the <a> element.

Like Boris said, putting a border on the <a> element will make it clearer what's going on.
Well, I've worked around it, but it's remeniscent of doing awful code hacks to accommodate the perverse behavior of IE6. I find it hard to imagine a situation in which one would actually use this fairly typical construct:

<a href="something"><img src="something"></a>

and would actually want anything OTHER than the img to act as the link. Apparently, neither can the Chrome and IE folks - neither browser does what FF does.
Unfortunately no-one from Google or Microsoft has ever proposed a standard for their behavior of treating some elements as transparent to events. It's not even clear whether they use the same behavior.

I actually find the Chrome behavior rather perverse ... as you can see in the testcase, an <a> element with text at each end and an image in the middle is clickable over the text, but seems to have a hole where the image margin is. If you add a border or a background --- even just a left border --- suddenly the whole element is clickable. I'm not sure that's an overall win in terms of matching author expectations.
Product: Core → Core Graveyard
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: