Nested div display problem with IE and Firefox.

[fred.haab]

Here's a page with a sample login:
http://frhaab.home.comcast.net/test/prob1.html

Ignore the part about centering.

The page is pretty self explanatory, but for archival purposes I'll
reiterate it here. The CSS is shown on the page I linked to above, but
the important part... the "clear" class, is really the only important
tag, and it just has "clear: both" set.

<form>
<div class="login border bg">
<div class="clear">
<div class="login-text">Username:</div>
<div class="login-input"><input type="text" name="username" /></div>
</div>
<div class="clear">

<div class="login-text">Password:</div>
<div class="login-input"><input type="password" name="password"
/></div>
</div>
<div class="clear">
<div class="login-text">&nbsp;</div>
<div class="login-input"><input type="submit" value="login" /></div>
</div>
</div>
</form>

Long story short, the login button is displayed beneath the outer login
div on both Firefox and Opera, and that seems counter intuitive to me.

IE displays it how I think it would be displayed.

The work-around is to add another empty div:

<div class="clear"></div>

After the submit button div, and before closing the outer div. This
displays correctly on all browsers. The question is why. I want to
know if I'm wrong, or if Firefox and Opera are wrong.

 

[Jonathan N. Little]

Here's a page with a sample login:
http://frhaab.home.comcast.net/test/prob1.html

After the submit button div, and before closing the outer div. This
displays correctly on all browsers. The question is why. I want to
know if I'm wrong, or if Firefox and Opera are wrong.

Simpler solution and only extra DIV I needed was the nested for the
submit button because of IE's lack of selector support, also converted
to proportional sizing to scale with font is zoomed, your method will
break...

FORM.login {
margin: 20px auto;
padding: .5em;
width: 18em;
border: 5px ridge;
background-color: #bfc6bd;
}

FORM.login LABEL {
display: block;
float: left;
margin: 0 .5em;
width: 5em;
text-align: right;
}

FORM.login DIV DIV {
margin: .5em;
text-align: center;
}


<form class="login">
<div>
<label for="username">Username:</label>
<input id="username" name="username" type="text">
<label for="password">Password:</label>
<input id="password" name="password" type="text">
<div><input value="login" type="submit"></div>
</div>
</form>

 

[fred.haab]

Simpler solution and only extra DIV I needed was the nested for the
submit button because of IE's lack of selector support, also converted
to proportional sizing to scale with font is zoomed, your method will
break...

Your workaround is fine, perhaps better than mine... but I already had
a work around, and the question was why it's happening (is it me or
Firefox/Opera that's got it wrong, and why).

Ignore the other aspects of the page, ignore the parts about centering
(I've already said this in the first post), it's not what I'm asking
about here.

 

[Jonathan N. Little]

Your workaround is fine, perhaps better than mine... but I already had
a work around, and the question was why it's happening (is it me or
Firefox/Opera that's got it wrong, and why).

It is you and IE that is wrong. Floats are supposed to break out of the
containing block so that a floated block can knock out more than one
non-floated block

+-----------------+
| Block 1 |
| |
|+------+ |
|| | |
+|Block |---------+
| 2 |
+| |---------+
|| | |
|+------+ |
| |
| Block 3 |
+-----------------+

Block 1 & 3 are standard non-floated paragraphs of text. With in Block 1
there is a DIV with an image and caption which is floated left. If its
height extends beyond the end of Block 1 It should displace both Block 1
& 3 as crudely illustrated above. I should not expand Block 1 nor push
down Block 3 like below unless Block 3 has "clear: left;" applied

+-----------------+
| Block 1 |
| |
|+------+ |
|| | |
+|Block |---------+
| 2 |
| |
| |
+------+
+-----------------+
| |
| |
| |
| |
| Block 3 |
+-----------------+

One should try to avoid replacing overly complex nesting of TABLEs for
layout with overly complex nesting DIVs! Getting a deeper understanding
of CSS can eliminate the need for unnecessary "presentational" DIVs and
SPANs. I am constantly amazed at ho much I can strip out and make the
markup leaner and still be very flexible. IE of course is usually the
fly in the ointment that necessitates either an added container or class
definition.

 

[fred.haab]

It is you and IE that is wrong. Floats are supposed to break out of the
containing block so that a floated block can knock out more than one
non-floated block

Actually, I disagree. In all my searching online, I've found that this
behavior is known and expected, but is not defined or "supposed" to be
that way.

In my searching, I've discovered that simply adding the style
"overflow: auto" to the outer div solves the problem.

 

[Wÿrm]

<[email protected]> kirjoitti
viestissä:[email protected]...

Actually, I disagree. In all my searching online,

There is no need to search that much. Read the w3 specs, they tell what
should happen.

I've found that this
behavior is known and expected, but is not defined or "supposed" to be
that way.

I suggest you should spend some time and read
http://www.w3.org/TR/CSS21/visuren.html#floats and how float is moved from
the normal flow.

"Since a float is not in the flow, non-positioned block boxes created before
and after the float box flow vertically as if the float didn't exist.
However, line boxes created next to the float are shortened to make room for
margin box of the float."

 

[Jonathan N. Little]

Actually, I disagree. In all my searching online, I've found that this
behavior is known and expected, but is not defined or "supposed" to be
that way.

No, I am sorry but your position is *incorrect*.

See:
http://www.w3.org/TR/CSS21/visuren.html#floats

and scroll down a bit to the diagram "A floating image obscures borders
of block boxes it overlaps." to see how floats overlap with boxes in
normal flow...

In my searching, I've discovered that simply adding the style
"overflow: auto" to the outer div solves the problem.

yes can work but sometimes can produce unwanted scroll bars, my way is
better for 2 reasons. 1) it removes superfluous containing markup and
classes and 2) it uses a contained normal flowed element to expand the
height of the container with no chance of scrollbars.

 

[fred.haab]

<[email protected]> kirjoitti
viestissä:[email protected]...



There is no need to search that much. Read the w3 specs, they tell what
should happen.



I suggest you should spend some time and read
http://www.w3.org/TR/CSS21/visuren.html#floats and how float is moved from
the normal flow.

"Since a float is not in the flow, non-positioned block boxes created before
and after the float box flow vertically as if the float didn't exist.
However, line boxes created next to the float are shortened to make room for
margin box of the float."

I still don't agree that this explains it away, though. The containing
div was created before, it's true, but it's a parent container, not
simply just another container that was created before the floated
container.

In other words, give this:

<div>
</div>
<div class="right">
</div>

The text makes perfect sense, but in this case:

<div><div class="right"></div></div>

The outer div is the parent, not simply some other box that was created
before or after.

 

[fred.haab]

Wÿrm wrote:

I still don't agree that this explains it away, though. The containing
div was created before, it's true, but it's a parent container, not
simply just another container that was created before the floated
container.

In other words, give this:

<div>
</div>
<div class="right">
</div>

The text makes perfect sense, but in this case:

<div><div class="right"></div></div>

The outer div is the parent, not simply some other box that was created
before or after.

Who is Jennifer Niederst Robbins? She wrote the "Web Design in a
Nutshell" for O'Reilly. That doesn't make her a goddess of HTML, she's
not one of the people who wrote the spec (as far as I know), she just
wrote a book. However, I found in her book what I remembered.... page
371, second bullet point about floats:

"The floated element stays within the content area of its containing
block (the nearest block-level ancestor element). It does not cross
into the padding."

So I think you guys are the ones misreading the specs... its not a
floated box before or after we're talking about, it's the containing
element.

 

[Jonathan N. Little]

I still don't agree that this explains it away, though. The containing
div was created before, it's true, but it's a parent container, not
simply just another container that was created before the floated
container.

In other words, give this:

<div>
</div>
<div class="right">
</div>

The text makes perfect sense, but in this case:

<div><div class="right"></div></div>

And if DIV class right has content then make is larger than the base of
the containing DIV is SHOULD extend beyond the base of out DIV. The out
DIV is not supposed to expand to accommodate a floating element.

The outer div is the parent, not simply some other box that was created
before or after.

 

[Jonathan N. Little]

Who is Jennifer Niederst Robbins? She wrote the "Web Design in a
Nutshell" for O'Reilly. That doesn't make her a goddess of HTML, she's
not one of the people who wrote the spec (as far as I know), she just
wrote a book. However, I found in her book what I remembered.... page
371, second bullet point about floats:

"The floated element stays within the content area of its containing
block (the nearest block-level ancestor element). It does not cross
into the padding."

I am sorry but it not what it says here, and they wrote the spec which I
thinks trumps!

www.w3.org/TR/CSS21/visuren.html#floats

Scroll down a bit as I said earlier to the 3rd diagram, "A floating
image obscures borders of block boxes it overlaps."

It shows and describes the very same behavior as a floated image
contained within the upper DIV, and the image extends beyond the base of
its container and displaces the DIV below. It *is* the correct behavior.
I am not making this up.

 

[fred.haab]

(e-mail address removed) wrote:

I am sorry but it not what it says here, and they wrote the spec which I
thinks trumps!

www.w3.org/TR/CSS21/visuren.html#floats

Actually, I have read this. And, in fact, Jennifer's bullet points
were a summary of that exact reference you site.

Scroll down a bit as I said earlier to the 3rd diagram, "A floating
image obscures borders of block boxes it overlaps."

Again, these diagrams are not showing a parent/child relationship, they
are one after the other.

It shows and describes the very same behavior as a floated image
contained within the upper DIV, and the image extends beyond the base of
its container and displaces the DIV below. It *is* the correct behavior.
I am not making this up.

In fact, it shows nothing of the kind as far as I can tell - they don't
give you complete markup and CSS to make that determination.

 

[Jonathan N. Little]

Actually, I have read this. And, in fact, Jennifer's bullet points
were a summary of that exact reference you site.


Again, these diagrams are not showing a parent/child relationship, they
are one after the other.

NO it indeed does shoe a parent/child relationship, The diagram shows to
adjacent blocks with red borders, but the upper on had a floated
*child* image. The diagram illustrates how the floated *child* image not
only breaks out of its containing block but also extending into the
block adjacent to its *parent*. This is made visible because the floated
image obscures the border and margins of the two blocks with normal flow.

When you float an element to take it out of the normal layout flow, just
like absolute positioning, but unlike absolute positioning floats
displace the contents of the elements they overlap whereas absolute
positioned element do not.

Another this to note is that a floated element by default will not
stretch a parent's right and left sides and well as the bottom. See for
yourself:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Float DEMO</title>

<style type="text/css">
.dad { width: 300px; height: 300px; margin: 20px; }
.junior { background-color: #fdd; float: left; }
.wideload { width: 500px; height: 100px; }
.stringbean { width: 100px; height: 400px; }
.first { background-color: #ffe; }
.second { background-color: #fef; }
.third { background-color: #eff; }
</style>

</head>
<body>

<div class="dad first">
The parent DAD here is only 300px wide.

<div class="junior wideload">
So JUNIOR here likes everything supersized so is 500px wide
</div>

So even though JUNIOR is <strong>child</strong> of DAD,
DAD does not stretch wider to contain JUNIOR's extra girth,
as it is supposed to be.
</div>

<div class="dad second">
And as with this DAD as well, DAD is just an old square at
300px tall.

<div class="junior stringbean">
But his boy is destine for the NBA at 400px tall!
</div>

And although his <q>boy</q> is also a child element he cannot
contant his extra hight when JUNIOR is floated.
</div>

<div class="dad third">
In fact, the second DAD's JUNIOR will stick his <q>feet</q>
within this poor guy who is adjacent to DAD number 2. This is
the defaul an proper behavior for floats within and adjacent
to elements with normal flow.
</div>

</body>
</html>

 

[fred.haab]

NO it indeed does shoe a parent/child relationship, The diagram shows to
adjacent blocks with red borders, but the upper on had a floated
*child* image. The diagram illustrates how the floated *child* image not
only breaks out of its containing block but also extending into the
block adjacent to its *parent*. This is made visible because the floated
image obscures the border and margins of the two blocks with normal flow.

Again, I'm not saying you're wrong about your interpretation of what
the page says, but the page does NOT show the markup for the image it's
displaying in those two diagrams (one with a clear, one without). The
small bit of markup it shows above is not complete. I can infer you
are right from the point by point they have a bit lower on the page -
they are quite clear about what happens left, right, and top - but they
don't mention bottom in any meaningful context.

The text also says "Here is another illustration, showing what happens
when a float overlaps borders of elements in the normal flow." It's
showing that the inline element (the P) overlaps the floated element
even though the text itself doesn't. It doesn't say, or imply, that
this is a parent/child relationship.

There is nothing to indicate that what it's displaying has any
relevence at all to the complete markup they show in the other example
above - they show NO markup for those two images.

 

[Jonathan N. Little]

I will agree that the spec is hardly an easy read, nor are the author's
expansive in their samples and illustrations, but in both the sample
code and diagrams they are showing the floated image as a child of a
block in normal flow. Their example:


<BODY>
<P>Some sample text <=[1]
<IMG src=img.png alt="This image will illustrate floats"> <=[2]
that has no other... <=[3]
Notes:
[1] They started the parent block with content here
[2] The child floated block, this case an image
[3] More of the parent block's normal flow content


Then in the first of the 2 diagrams they show the parent block with a
red border. It has content "Some sample text..." that precedes the
floated image, show in grey with an 'x'. The rest of the parent
paragraph's content flows around the floated image as it should. The
floated image extends beyond the bottom border and margin of the parent,
as it should, and does *not* expand the parent. This is the issue with
your own floated child that you were complaining about, right? In
addition the diagram shows how the the floated child of the 1st
paragraph injects into the one below! As it should.

Next is shows what happens when you add clear property to the parent
blocks. Notice in the 2nd diagram that the clear property on the P
elements prevents the image from injecting into the second paragraph's
content area, it does not cross over the red border (It does enter the
2nd P's margin space the space is the floated block's margin that does
not collapse) But the important thing to note here is that floated image
still *does* break out of its parent paragraph in the diagram, it
crosses the red border. the 1st P does not expand.

Again, I'm not saying you're wrong about your interpretation of what
the page says, but the page does NOT show the markup for the image it's
displaying in those two diagrams (one with a clear, one without). The
small bit of markup it shows above is not complete. I can infer you
are right from the point by point they have a bit lower on the page -
they are quite clear about what happens left, right, and top - but they
don't mention bottom in any meaningful context.

The text also says "Here is another illustration, showing what happens
when a float overlaps borders of elements in the normal flow." It's
showing that the inline element (the P) overlaps the floated element
even though the text itself doesn't. It doesn't say, or imply, that
this is a parent/child relationship.

Yes it does, as I said above it shows content text within the first
paragraph above the floated image. The grey rectangle's top is within
the content area (within the red border) of the parent. And it shows it
breaking out of the paragraph's bottom border.

There is nothing to indicate that what it's displaying has any
relevence at all to the complete markup they show in the other example
above - they show NO markup for those two images.