151614 - div with relative css forgets it is affected by a float

Status: RESOLVED WORKSFORME

(Core :: Layout: Floats, defect)

Description

[David Anderson]

see url.

divs inside an h1 float left of another h1 div appropriately, except for when
the div is ccs'd with a relative position.

( On a larger page you can see the to rel div's right on top of each other,
however, in my test case, the floated div appears gone, with the non-floated div
where the floated div should be )

it looks good in ie..

Comment 1

[David Anderson]

I'm changing the test case a little...
new test case demonstrates the same problem, just the floated rel div is knocked
down by the rel div that not inside a floater...

Comment 2

[Amarendra Hanumanula]

 Confirming on both branch and trunk builds: 2002-06-14. Win2K.

Comment 3

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

Part of the reason it doesn't look the way you want is that you need to specify

h2 { margin: 0; }

if you want the h2 margin to disappear.  You can argue over whether that's a
bug, but it's probably not a bug in Mozilla.

Another part of the reason it doesn't look the way you want is that the
backgrounds of blocks aren't supposed to wrap around floats -- they're supposed
to fit behind floats.  So the background behind Name should run behind the
background of ID.

However, the fact that the text "Name" is in the wrong place does seem like a
valid bug.

Comment 4

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

Attachment: testcase for the valid part of the problem

Comment 5

[David Anderson]

Sorry for any confusion.  I put the borders and background-colors to illustrate
the boxes.  The only problem I was paying any attention to was the 'name'
problem.  Thanks for clarifying what I wanted to be noticed.

Comment 6

[WADA Masato]

Hello.

As the specification does not explicitly tell the relationships between float
and relative positioning, I am not clear about how inline texts in a relative
positioned box preceded by floated boxes should be rendered.

Relative is positioned. Being OFFSET relative to its normal position.
Indeed, this relative positioned block-box is rendered just the same as
no-positioned block-boxes, vertically and horizontally. I do not think the
inline text contents that live in the relative positioned box should be affected
by the preceding float(ed) box.

I am not confident, but is this really a bug?

Comment 7

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

No, it's not laid out the same, since the text isn't wrapping around the float.
 It is really a bug.

Comment 8

[David Anderson]

Changing the summary to something more appropriate.
(If this isn't improving the summary, let me know...)

Comment 9

[WADA Masato]

>>#7
You mean when the text is wrapping around the float the quadrangular  block-box
could turn into a reentering polygon?
I do not think it is right...

Comment 10

[WADA Masato]

Sorry.
I read #3 again, and have noticed #9 is groundless.
Now I have recognized #3 is everything, and it is out of place to discuss
relationships between float and relative positioning here.
Thank you.

Comment 11

[Sedat Kapanoglu]

Another case: http://sozluk.sourtimes.org/show.asp?t=kurt+vonnegut

Comment 12

[James Pharaoh]

This causes problems because setting such things to be relative next to a float
fixes some nasty bug in ie6. so do i make it work in ie and not in netscape? i
migh thave to for an e-commerce site...

Comment 13

[Boris Zbarsky [:bzbarsky]]

So what exactly is the bug?  The fact that the background of "Line 1" is over
the floater?  "Line 1" and "Line 2" line up the text the same exact way....

Comment 14

[David Anderson]

Well, this looks at least partially fixed.
Previous versions of Moz had the relative div, the one inside the float (with
the text 'Name'), falling out of the float (and over the unfloated h2).

Let me see if I have any other issues.

However, it looks like the main impetus for this bug has been fixed (looking at
it in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030411
Phoenix/0.5+)

Comment 15

[David Anderson]

Let me correct that last explaination:

>Previous versions of Moz had the relative div, the one inside the float (with
>the text 'Name'), falling out of the float (and over the unfloated h2).

Previous versions of Moz had the relative div (containing 'Name') (the one that
is inside the H2 (CONTAINING 'Name' and 'Mozilla') WHICH IS PUSHED OUT BY THE
FLOAT) falling out of ITS PARENT H2 CONTAINER (and over into the FLOATED DIV).

The problem is still that the relative div inside unfloated h2 is moving into
the float.

What's changed 'recently' is that the text inside the relative div inside the
unfloated h2 is still being constrained by the unfloated h2 ( even though the
relative div which more closely contains it (the relative div inside the h2) is
not being constrainted by the h2 )

Maybe a better way of saying it is that the text is affected by the float, but
not the box

Ps. I also tried to make the h2 containing Name and Mozilla (the unfloated one)
a relative positioned h2.  Here the same thing happened where the h2 box forgets
the float and moves over the floating div, but the text is still pushed out by
the float.

(Also seeing this with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b)
Gecko/20030427))

Comment 16

[David Anderson]

(The last 2 responses refer to the bug url 
http://mason.gmu.edu/~danders2/relativeNoFloat.html
)

Baron's attachment, while clarifying the issue on Moz's previous behavior (text
failing through), is not the same test case.

In the bug url 'test case', the box that fails through affects the float (it
pushes the elements inside the float down) when that box should be
contained/affected by its non-relative h2 parent instead.

Comment 17

[Boris Zbarsky [:bzbarsky]]

> Maybe a better way of saying it is that the text is affected by the float, but
> not the box

Boxes are not affected by floats. Text is. See comment 3.  So is the problem
that the background is _above_ the float instead of _below_ it (z-order wise)?

Comment 18

[David Anderson]

Boris, you are right.  And Baron's test case is fine.

I've changed the page on the url to make it slightly less confusing.

This is what was the problem was...

I started with a float and a div

+-------+-------+
|       | [div] |
| float | div   |
+-------+       |
|               |
+---------------+

Life is good.

But then I made [div] into a rel

*older moz*

+-------+-------+
| ->[rel div   ]|
| float | div   |
+-------+       |
|               |
+---------------+

Not good.

I wanted.

+-------+-------+
|       | ->[rel div   ]
| float | div   |
+-------+       |
|               |
+---------------+

However, what the code was really asking for was...

+-------+-------+
| ->[   !  rel div   ]
| float |  div  |
+-------+       |
|               |
+---------------+

which is how it looks now. So, WORKSFORME.


There is still the noticable z-order issue which both Zbarsky and Baron pointed out.

That is being handled by Bug 191830.