Closed
Bug 217314
Opened 21 years ago
Closed 20 years ago
[EVENTTARG]relatively positioned box covers sibling floats
Categories
(Core :: Layout: Floats, defect)
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:
Comment 1•21 years ago
|
||
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.
Reporter | ||
Comment 2•21 years ago
|
||
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?
Comment 3•21 years ago
|
||
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.
Reporter | ||
Comment 4•21 years ago
|
||
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.
Comment 5•21 years ago
|
||
Comment 6•21 years ago
|
||
This looks like bug 46117?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
OS: Windows 2000 → All
Whiteboard: DUPEME
Reporter | ||
Comment 7•21 years ago
|
||
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.
Comment 10•21 years ago
|
||
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
Comment 11•21 years ago
|
||
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?
Comment 12•21 years ago
|
||
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
Comment 13•21 years ago
|
||
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.
Reporter | ||
Comment 14•21 years ago
|
||
The url isnt valid anymore so I removed it.
Comment 15•21 years ago
|
||
Could we get that ruling on what CSS2.1 says about the z-ordering here?
Comment 16•20 years ago
|
||
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
Comment 17•20 years ago
|
||
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.)
Comment 18•20 years ago
|
||
> 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.
Comment 19•20 years ago
|
||
>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.
Comment 20•20 years ago
|
||
*** This bug has been marked as a duplicate of 102695 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Comment 21•19 years ago
|
||
*** Bug 309605 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•