By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,624 Members | 2,179 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,624 IT Pros & Developers. It's quick & easy.

Floating Div problem

P: n/a
Hello,

I've tried to solve this problem six ways from sunday, but I'm
conceding defeat and asking for help at this point.

The following site is rendering *very* oddly in Mozilla only. IE seems
to lay it out just fine:

http://pythonphotos.org

The images included in the page which should be floating below the
second H2, are instead pushed all the way to the bottom of the page
(but just above the footer). Adding an element below the images with
'clear: both' didn't help either.

You can see the same problem on a detail page as well:
http://pythonphotos.org/archive/181/view

I've tried using extra spans, containing divs, and adjusting the CSS
in just about every way I can think of, all to no avail. IE
(ironically enough) renders the site as intended, and Mozilla doesn't.

Any suggestions?

- Michael Bernstein
Jul 20 '05 #1
Share this Question
Share on Google+
16 Replies


P: n/a
On Mon, 10 May 2004, Michael Bernstein wrote:
I've tried to solve this problem six ways from sunday, but I'm
conceding defeat and asking for help at this point.


Validate first. Ask questions afterwards.

The "bookmarklets" at W3C make validation very easy; or you might
prefer the "web developer's toolbar" for Mozilla/Firefox at
http://www.chrispederick.com/work/firefox/webdeveloper/

Fiddling with details is futile until the groundwork had been done.
Honestly - no matter what the tag-soup slurpers will want you to
believe.
Jul 20 '05 #2

P: n/a
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote in message news:<Pi*******************************@ppepc56.ph .gla.ac.uk>...
On Mon, 10 May 2004, Michael Bernstein wrote:
I've tried to solve this problem six ways from sunday, but I'm
conceding defeat and asking for help at this point.


Validate first. Ask questions afterwards.
[snippage]
Fiddling with details is futile until the groundwork had been done.
Honestly - no matter what the tag-soup slurpers will want you to
believe.


The invalidity was minor, and only put into otherwise valid CSS in
order to fix an oddity in IE5's rendering of table text a bit too big.
I've removed it now, the HTML and CSS validate, and my Mozilla
rendering problem remains.

Help, please?

- Michael Bernstein
Jul 20 '05 #3

P: n/a
On 10 May 2004 21:43:48 -0700, Michael Bernstein <we******@cox.net> wrote:
The invalidity was minor, and only put into otherwise valid CSS in
order to fix an oddity in IE5's rendering of table text a bit too big.
I've removed it now, the HTML and CSS validate, and my Mozilla
rendering problem remains.

Help, please?


What's this width hack you're using? Seems to me this might be a cause of
trouble. Try eliminating the hack and see if it solves the issue.
Jul 20 '05 #4

P: n/a
Neal wrote:
On 10 May 2004 21:43:48 -0700, Michael Bernstein <we******@cox.net> wrote:
The invalidity was minor, and only put into otherwise valid CSS in
order to fix an oddity in IE5's rendering of table text a bit too big.
I've removed it now, the HTML and CSS validate, and my Mozilla
rendering problem remains.

Help, please?
What's this width hack you're using?


It's the box-model hack, a work-around for an IE rendering bug:
http://css-discuss.incutio.com/?page=BoxModelHack
Seems to me this might be a cause
of trouble. Try eliminating the hack and see if it solves the issue.


OK, I removed it. Now IE5 looks worse, and Mozilla no better. IE6 now
has the best rendering.

What should I try next?

- Michael Bernstein
Jul 20 '05 #5

P: n/a
Michael Bernstein wrote:
Hello,
I've tried to solve this problem six ways from sunday, but I'm
conceding defeat and asking for help at this point.
The following site is rendering *very* oddly in Mozilla only. IE seems
to lay it out just fine:
http://pythonphotos.org

The images included in the page which should be floating below the
second H2, are instead pushed all the way to the bottom of the page
(but just above the footer). Adding an element below the images with
'clear: both' didn't help either.

[snip]

I don't know why, but I think your sidebars on the right are interfering. You
float several of them right, and clear them, so I would have thought this
should work. But something I don't understand is then intefering with what is
on the left.

Try a different approach. Put *all* the sidebar on the right into a single
container. (Eg. just remove the </div><div> between them). This may cause what
is on the left to work.

I notice that your page looks OK in Opera 7.23 as well as IE. That is a bit
suspicious. Are you pushing the boundaries a bit?

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #6

P: n/a
Barry Pearson wrote:
Michael Bernstein wrote:
Hello,
I've tried to solve this problem six ways from sunday, but I'm
conceding defeat and asking for help at this point.
The following site is rendering *very* oddly in Mozilla only. IE seems
to lay it out just fine:
http://pythonphotos.org

The images included in the page which should be floating below the
second H2, are instead pushed all the way to the bottom of the page
(but just above the footer). Adding an element below the images with
'clear: both' didn't help either.
[snip]

I don't know why, but I think your sidebars on the right are interfering. You
float several of them right, and clear them, so I would have thought this
should work. But something I don't understand is then intefering with what is
on the left.

Try a different approach. Put *all* the sidebar on the right into a single
container. (Eg. just remove the </div><div> between them). This may cause what
is on the left to work.


Ah-ha! This is progress!

I did as you suggested, and the problem went away! I then experimented
with putting some of the </div><div> back and came to this conclusion:

If the sidebar 'breaks' below the top of the floated image, the image
then moves down to the top of the sidebar. So, by making sure that the
sidebar only breaks once at the top of the page (as it is set now) I
avoid interfering with the layout.

This is all *very* confusing though. *why* should the right sidebars
interfere with the left floated image in this way? By everything I
understand of CSS, that shouldn't happen unless the floated image is
'clear: right', which it isn't.
I notice that your page looks OK in Opera 7.23 as well as IE. That is a bit
suspicious. Are you pushing the boundaries a bit?


I didn't think I was doing anything particularly tricky. Even the
simplified box-model hack I was using before to fix IE5 was (I thought)
relatively tame.

A few minor tweaks to widths and margins, and the (modified) layout
works perfectly on Mozilla and IE6. IE5 still has a few minor problems,
but I can fix those again with the box-model hack.

Before I give up on splitting the sidebar div, could this be a bug in
Mozilla? Or *am* i doing something tricky without realizing it?

- Michael Bernstein
Jul 20 '05 #7

P: n/a
Michael Bernstein wrote:
Barry Pearson wrote: [snip]
Try a different approach. Put *all* the sidebar on the right into a
single container. (Eg. just remove the </div><div> between them).
This may cause what is on the left to work.


Ah-ha! This is progress!

I did as you suggested, and the problem went away! I then experimented
with putting some of the </div><div> back and came to this conclusion:


Glad to help.

[snip] This is all *very* confusing though. *why* should the right sidebars
interfere with the left floated image in this way? By everything I
understand of CSS, that shouldn't happen unless the floated image is
'clear: right', which it isn't.
I agree. If you had hit the problem with IE, I would just have shrugged. IE
can be very buggy indeed with floats. Sometimes it is simply non-compliant;
sometimes it just chooses to throw half your content away!

But I simply couldn't spot anything you were doing wrong! Perhaps it is in the
small print about floats, which governs their highest point. But not only did
you have a clearing div, I copied your HTML & CSS into Dreamweaver, and
cleared your headers left too. Yet the images still went below the headers. If
this is compliant behaviour, it has opened up a whole new area of the spec.

[snip] Before I give up on splitting the sidebar div, could this be a bug in
Mozilla? Or *am* i doing something tricky without realizing it?


I hate to stick my neck out, but this could be a bug in Mozilla that is not in
IE & Opera! I just don't know - you are on your own.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #8

P: n/a
Barry Pearson wrote:
Perhaps it is in the small print about floats, which governs their
highest point. But not only did you have a clearing div, I copied
your HTML & CSS into Dreamweaver, and cleared your headers left too.
Yet the images still went below the headers. If this is compliant
behaviour, it has opened up a whole new area of the spec.

I hate to stick my neck out, but this could be a bug in Mozilla that
is not in IE & Opera!


It is a bug in Mozilla, as L. Raittali has pointed out in the past.
Mozilla pushes floats down when it shouldn't. Opera gets it right. IIRC,
in tests that I created, IE/Win got it wrong, too.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/
Jul 20 '05 #9

P: n/a
Brian wrote:
Barry Pearson wrote:

[snip]
I hate to stick my neck out, but this could be a bug in Mozilla that
is not in IE & Opera!


It is a bug in Mozilla, as L. Raittali has pointed out in the past.
Mozilla pushes floats down when it shouldn't. Opera gets it right.
IIRC, in tests that I created, IE/Win got it wrong, too.


Thanks for that. I've been desperately looking without success at the small
print.

In *this* case, it appears that IE (5 & 6) / Win got it right too.

(Sigh! If we can't even rely on IE being the one that is wrong ... !)

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #10

P: n/a
Barry Pearson wrote:

Brian wrote:

It is a bug in Mozilla, as L. Raittali has pointed out in the past.
Mozilla pushes floats down when it shouldn't. Opera gets it right.
IIRC, in tests that I created, IE/Win got it wrong, too.


Thanks for that. I've been desperately looking without success at the small
print.

In *this* case, it appears that IE (5 & 6) / Win got it right too.

(Sigh! If we can't even rely on IE being the one that is wrong ... !)


Susanne Jaeger (on the css-d mailing list) pointed out that according to
the spec, Mozilla's implementation may be the correct one:

http://www.w3.org/TR/2004/CR-CSS21-2...float-position

"5. The outer top of a floating box may not be higher than the outer
top of any block or floated box generated by an element earlier in the
source document"

If this interpretation of the spec is correct, Mozilla's implementation
would be more conformant, but less intuitive (at least to me). This
might qualify as a bug in the specification, because it doesn't seem to
take element nesting into account.

The behavior I would expect (as a designer) would be something more like:

"5. The outer top of a floating box may not be higher than the outer top
of any block or floated box generated by an element earlier in the
source document that is directly within the same containing block."

Cheers,

- Michael Bernstein
Jul 20 '05 #11

P: n/a
Brian wrote:

Barry Pearson wrote:
Perhaps it is in the small print about floats, which governs their
highest point. But not only did you have a clearing div, I copied
your HTML & CSS into Dreamweaver, and cleared your headers left too.
Yet the images still went below the headers. If this is compliant
behaviour, it has opened up a whole new area of the spec.

I hate to stick my neck out, but this could be a bug in Mozilla that
is not in IE & Opera!


It is a bug in Mozilla, as L. Raittali has pointed out in the past.
Mozilla pushes floats down when it shouldn't. Opera gets it right. IIRC,
in tests that I created, IE/Win got it wrong, too.


Brian, I've googled around a bit, and can't find any reference to 'L.
Raittali'. Can you give a URL to the appropriate bug report?

Thanks,

- Michael Bernstein
Jul 20 '05 #12

P: n/a
Michael Bernstein wrote:
Barry Pearson wrote: [snip]
Thanks for that. I've been desperately looking without success at
the small print.

[snip] Susanne Jaeger (on the css-d mailing list) pointed out that according
to the spec, Mozilla's implementation may be the correct one:
http://www.w3.org/TR/2004/CR-CSS21-2...float-position

"5. The outer top of a floating box may not be higher than the outer
top of any block or floated box generated by an element earlier in the
source document"

If this interpretation of the spec is correct, Mozilla's
implementation would be more conformant, but less intuitive (at least
to me). This might qualify as a bug in the specification, because it
doesn't seem to take element nesting into account.
Chuckle! Thanks. That has given me something to go on. I 10% suspected it in
my earlier post, when I said "Perhaps it is in the small print about floats,
which governs their highest point". I have fallen foul of this in the past.
The behavior I would expect (as a designer) would be something more
like:

"5. The outer top of a floating box may not be higher than the outer
top of any block or floated box generated by an element earlier in the
source document that is directly within the same containing block."


Remember - CSS1 (which introduced floats) was *explicitly* not a layout
language. Perhaps we can't complain if we try to treat it like one, and fail.
http://www.w3.org/TR/REC-CSS1#appendix-e

I put complex stuff into floated boxes. But then I float the entire box.
Perhaps that is the lesson for you. (Or use absolute positioning. Or a simple
layout table).

Good luck - you appear to have enough clues to publish something useful.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #13

P: n/a
In message <Pi*******************************@ppepc56.ph.gla. ac.uk>,
Alan J. Flavell <fl*****@ph.gla.ac.uk> writes
The "bookmarklets" at W3C make validation very easy;
Alternative Bookmarklets:

<http://www.squarefree.com/bookmarklets/>

(includes those for many other functions, not related to validation, and
for several browser types).
or you might prefer the "web developer's toolbar" for Mozilla/Firefox
at http://www.chrispederick.com/work/firefox/webdeveloper/


An alternative toolbar for web developers using IE5/6:

<http://www.nils.org.au/ais/web/resources/toolbar/update.html>
--
Andy Mabbett
"The Internet is a reflection of our society[ ...]. If we do not like what we
see in that mirror the problem is not to fix the mirror, we have to fix
society." Vint Cerf
Jul 20 '05 #14

P: n/a
Michael Bernstein wrote:
Brian, I've googled around a bit, and can't find any reference to 'L.
Raittali'.
Sorry for the wild goose chase. "L. Raittali" is none other than our own
Lauri Raittila. Yes, I mispelled the last name, my apolgies to you and
him. LR is a ciwas regular, an Opera evengelist of sorts, and one of the
better css debuggers I've met. And he knows the spec rather well, too.
Can you give a URL to the appropriate bug report?


Normally, I'd make you find it, but I already sent you on fruitless
search. :-)

http://groups.google.com/groups?selm...ews.cis.dfn.de

Read other messages in that thread, too, for some context.

HTH
--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/
Jul 20 '05 #15

P: n/a
Michael Bernstein wrote:
Brian wrote:
It is a bug in Mozilla, as L. Raittali has pointed out in the past.
Mozilla pushes floats down when it shouldn't. Opera gets it right. IIRC,
in tests that I created, IE/Win got it wrong, too.
Brian, I've googled around a bit, and can't find any reference to 'L.
Raittali'.


He most likely means me. People seem to have problem spelling my name,
not long ago someone called me Laur*a*
Can you give a URL to the appropriate bug report?


I posted a Mozilla bug report number here about something on floats, but
I have not followed this thread closely enough to know if this is same
issue. That discussion was easy to find:
http://google.ca/groups?&threadm=MPG...%40news.cis.df
n.de

I have also pointed out n+1 other times that somebodys idea of how floats
should be rendered is incorrect, so this is not necessarily what Brian is
referring...

Also, there is change between CSS2 and CSS21 on float rendering, that
Opera 7 don't get right, haven't tested on Mozilla, which I don't think I
have written in English. It was something relating collapsing margins,
which is my other pet subject...

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
I'm looking for work | Etsin työtä
Jul 20 '05 #16

P: n/a
Michael Bernstein wrote:

2nd response to this:
Barry Pearson wrote:
>
[snip] Susanne Jaeger (on the css-d mailing list) pointed out that according
to the spec, Mozilla's implementation may be the correct one:

[snip]

Whether or not Mozilla was right to position the images where it did, it was
not right to ignore the div with the { clear: left } that followed it, or the
same property I applied to h2s when experimenting. See:

CSS2
http://www.w3.org/TR/REC-CSS2/visuren.html#flow-control
left
The top margin of the generated box is increased enough that the top border
edge is below the bottom outer edge of any left-floating boxes that resulted
from elements earlier in the source document.

CSS2.1
http://www.w3.org/TR/2004/CR-CSS21-2...l#flow-control
left
The clearance of the generated box is set to the amount necessary to place the
top border edge below the bottom outer edge of any left-floating boxes that
resulted from elements earlier in the source document.

Either of these should have forced the div down, surely?

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #17

This discussion thread is closed

Replies have been disabled for this discussion.