35262 - Hotspots on IMG positioned w/ CSS not in right spot and not stable

Status: VERIFIED WORKSFORME

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

Description

[Alec Lazarescu]

Mozilla M14 and NN 6 Preview

If you put an href surround an img in a div and position the div, the hotspot on
the img seem to be below the actual image and mouse cursor doesn't always change
to a hand (hover over and off a few times).  This incorrect behavior was noticed
in IE4, but was not present in IE5 or NN4.x.

Click on the Timeline example on the URL above to see a sample CSS layout ripped
out of a test application.  Hover over the circles on the timelines (1993, etc)
to see the hotspot error.

Comment 1

[Hixie (not reading bugmail)]

That page uses very invalid CSS, such as "width:20" and HTML-like comments in
CSS blocks, both of which will be ignored by our standards compliant parser.

Check that page with the W3C CSS validator:
   http://jigsaw.w3.org/css-validator/validator-uri.html

Secondly, could you provide us with a very simplified test case? I think the
whole issue could be boiled down to an absolutely positioned anchor containing
an image, where the image's height is taller than the line-height of the anchor.

I also believe that this is in fact a DUP of bug 5693. But without a simpler
test case, it is difficult to tell.

Comment 2

[Alec Lazarescu]

I made the CSS compliant and I've just stripped the page so much that it now 
works fine... Hmm.  Going to work on adding things back in until it breaks 
again.  Will post when new page is ready.

Comment 3

[Hixie (not reading bugmail)]

Cool, thanks.

Comment 4

[Alec Lazarescu]

http://demo.intellipro.com/nn6/timeline.htm

Ok, I figured it out!  Check out the page above again.  The "panleft" arrow 
causes the problem.  If I set the z-index on the "panleft" to 1, the circle 
hotspots work fine.  If it's at 2 (same level) they don't.  This is definetely 
a bug since they are not overlapping or anything so they should be able to co-
exist on the same z-index.

This was a tough one to sort out!

Comment 5

[Hixie (not reading bugmail)]

David: looks like another [EVENTARG] type of problem.
Alec: Nice work on the simplifying! Thanks.

Comment 6

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

Based on the simplfied testcase, I think this bug is INVALID.  If you add the
CSS rule:

#panleft { background: red; }

you'll see that that absolutely positioned DIV spans the whole width of the page
(at least it should...).  When Troy implements the revised absolute positioning
rules, I think this will change.  Giving it an explicit width would also fix the
problem.

Since the div with id panleft has the same z-index and is later in the document,
it should take events away from the buttons that it is on top of (even though it
is transparent).

Comment 7

[Alec Lazarescu]

Ok, the explicit width does fix it.  However, shouldn't the preferred size (to 
borrow a java term) of a DIV be the maximum width of its contents and that's 
what it's implicit width should be?  The DIV isn't just transparent, there's 
simply no element to the right of the panleft arrow in that DIV.  

I browsed the CSS specification and I didn't see it mention whether a DIV spans 
the page by default so maybe it's up to the implementer (bad for standards!).

IE4 and Mozilla seem to have implicit page span DIVs
IE5 and NN4.x have implicit preferred size DIVs

Up to you guys, but I'd go with the next gen browser style if the W3C spec 
doesn't say otherwise.

Comment 8

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

The CSS spec very definitely *does* say.  However, the parts relating to
*absolutely positioned elements* (and only absolutely positioned elements) are
likely to change in the near future.  They are sections 10.3.7 and 10.6.4.

Comment 9

[Marc Attinasi]

The testcase works correctly as it is. Based on the discussion and the fact that 
it works correctly I am marking this WORKSFORME. Please reopen and explain if I 
am in error.

Comment 10

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

Yes, Troy changed the absolute positioning rules a few weeks ago.

Comment 11

[Stephen Walker]

verified using 2000071720 nightly build on w2k