Closed Bug 217314 Opened 21 years ago Closed 20 years ago

[EVENTTARG]relatively positioned box covers sibling floats

Categories

(Core :: Layout: Floats, defect)

x86
All
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 102695

People

(Reporter: jabernet, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: qawanted, testcase)

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624

Bug 5387 could be simmilar to this.
When I change the CSS of the #RightBar to remove the float:right properity the
links work fine. I don't know if this is because of the float or the other CSS
its embedded in. If I have time ill prepare a proper testcase.

Reproducible: Always

Steps to Reproduce:
div#Content is covering it

#Content {
   position: relative;
   margin-top: 15px;
   margin-left: 15px;
   margin-right: 10px;
}

Strangely enough, the UL does not recognize the floating section there, but the
LIs do and keep themselves from covering it.
Thanks for your fast response. Now I can fix it by removing position:relative
from #Content. But is this behaviour really correct? Shouldn't it both be same
behaviour? 
I don't know, I've only read a few parts of the spec. 

For anyone who would know - here's a testcase. The main paragraph with
position:relative covers the floating div, but still wraps around it.
Some more input: 
IE wraps the content and the box (it ignores position:relative imho) while Opera
7 doesn't wrap the box nor the content, so no floting occurs at all. Maybe Opera
is right in its behaviour, maybe its IE (I'd rather go for Opera).

And another thing: when I remove position:relative so floating occurs, IE and
Opera wrap the text correctly while mozilla only wraps paragraph for paragraph. 
Attached file Testcase
This looks like bug 46117?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
OS: Windows 2000 → All
Whiteboard: DUPEME
I think its not exactly the same as 46117 because the content ajusts and floats
round the div, while the div itself superpose the link. This doesn't happen if
you don't set position:relative, which should not make that much of a difference
(but I must admit that I don't know the specs).
Summary: Links in float-div are have no hover effects and are not usable → Links in float-div have no hover effects and are not usable
This is basically invalid, unless we want to "fix" bug 102695 (so it should be
marked as a duplicate).

But I want to double-check the CSS 2.1 z-index rules first...
I am attaching a file that demonstrates this bug (I think it's the same bug as
this one -- if not, then it's a new bug).

The attached filed renders OK in IE, but not in any Moz/Firebird/Netscape to
which I have access.

Rendering the attached file, as is, results in the "Home" link not being
rendered as a clickable link. Removing the "float: left" from that element
renders it clickable.

This behaviour is reproducible, even if one manually changes the z-order of the
two elements.
Since there seems to have been no activity on this bug, I don't suppose that
this will come as any surprise, but I just wanted to state explicitly for the
record that this bug is still present in the official Moz 1.5 release.

  Doc
Try the URL http://www.e-conomist.fsnet.co.uk/

The comments about z-index above seem to be a red-herring. A very subjective
analysis suggests that the 'floated' enclosing <div> disables links. I don't
know whether you have to read the spec to see that this is a bug, as it works
fine in other non-mozilla browsers. Is there any chance of promoting the
priority level?
Yes. The z-index thing is totally irrelevant. I guess I hadn't made it clear in
my earlier posting, but this bug is indeed triggered by the presence of the
floating option inside the <div>.

I am really surprised that loads of people haven't clamoured for this to be fixed.

Summary: Links in float-div have no hover effects and are not usable → [EVENTTARG]relatively positioned box covers sibling floats
I see that the title just got changed. I guess there is a good reason for it,
but the old title was sure a whole lot more obviously correct, at least as far
as the user is concerned.

Speaking just as a user, I know that the dimensions of my boxes (in the example
I posted a couple of months ago) are such that they do not overlap, whereas the
new title makes it sounds like this is some sort of "covering" problem (which it
may be from a code perspective, but it isn't from the user's perspective). The
original title, which talked about links in floating <div>s not being
clickable/usable, was a much more accurate description of the bug as it is
perceived by the user.

The only reason for my mentioning this is that anyone trying to report this bug
is unlikely to associate the current bug title with the bug that he is seeing,
so I doubt that it will be long before someone re-reports it using something
like the original words :-(

Anyway, I'm very glad that at least it looks like someone is looking into this;
it's the one thing that's stopping me from putting a "Use a Better Browser"
button on my corporate page -- (it would be a bit silly to do that, since the
page renders OK in IE, but not in Moz/Firebird!).

Incidentally, Konqueror renders the example page I posted here correctly -- the
link is clickable, the same as with IE.





The url isnt valid anymore so I removed it.
Could we get that ruling on what CSS2.1 says about the z-ordering here?
Depends on: 102695
Keywords: qawanted
http://www.w3.org/TR/CSS21/visuren.html#z-index

In the middle of the section there is a list of rules for the stacking levels
from back to front.

When you apply these rules to testcase
http://bugzilla.mozilla.org/attachment.cgi?id=130432&action=view
Rule nr. 4 applies for the div id="link"
Rule nr. 6 applies for the div id="paragraph"
So in this case these two divs overlap and afaik it is correct that div
id="paragraph" overlaps the div id="link"

So basically Mozilla is doing the right thing here, I think, except for bug
102695 perhaps 
But look at http://bugzilla.mozilla.org/attachment.cgi?id=132437&action=view;
the two elements in this example do not overlap at all (at least, not on any
reasonable size monitor), so the stacking order should not matter. 

Also, even if you modify this example so as to explicitly control the order of
stacking, there seems to be no order that results in the "Home" link being
clickable. (I tried both possible orders; neither worked.)

Or is this test case really an example of bug 106295? (Although 106295 seems to
be talking about transparency, which isn't mentioned here at all. To be
perfectly honest, I don't understand bug 106295 at all. All I really have much
confidence in is that
http://bugzilla.mozilla.org/attachment.cgi?id=132437&action=view looks [to me]
like it's a bug. Every other non-Moz-based browser I have tried, which is a
bunch of them, does what I would expect: allows one to click on the "Home" link.)

> the two elements in this example do not overlap at all

Yes they do.  Put some borders on the div to see where it's located and what its
size is.
>Every other non-Moz-based browser I have tried, which is a
>bunch of them, does what I would expect: allows one to click on the "Home" link.

When I use Opera 7.23 (WinXP), I am -just like in Mozilla- not able to click on
the link.

*** This bug has been marked as a duplicate of 102695 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
*** Bug 309605 has been marked as a duplicate of this bug. ***
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: