«

http://1-large-world.com/stargate/movie/moz.jpg
Screen shot page.

http://1-large-world.com/stargate/movie/tooltip3.html
Coded page.

The white and black bordered divisions do not "float" left of the red
bordered one as they're supposed to.
In IE and Opera they do.
Any clues as to why?

"Richard" <anonymous@127.000> wrote in message
news:...
> http://1-large-world.com/stargate/movie/moz.jpg
> Screen shot page.
>
> http://1-large-world.com/stargate/movie/tooltip3.html
> Coded page.
>
> The white and black bordered divisions do not "float" left of the red
> bordered one as they're supposed to.
> In IE and Opera they do.
> Any clues as to why?

In fact it is IE and Opera that are getting this wrong. Mozilla is
displaying things exactly as they should be.

Go to the spec and read up on exactly how float works, with particular
reference to the box model.

A floated element (div in this case) is totally removed from the flow. That
means any following divs will be layed out as if the floated div were not
there. This is what Mozilla is doing correctly. IE incorrectly positions
subsequent div's to the right of the floated one, particularly if you switch
on quirks mode, which you have done.

Once the rest of the page is layed out the floated div is re-inserted to the
left of where it would have been, at the left edge of its containing
ancestor (the body element in this case).

If any *content* from the non floated div's overlap the floated div then
that *content* is positioned to the right of the floated div and reflowed
(possibly causing the divs themselves to grow vertically). Note it is the
*content* that is moved, not the actual div. Thus, we get exactly what you
are seeing, overlapped borders.

If you want the white and black divs (and the <hr> for that matter) to have
their borders aligned to the right of the floated div then you should give
them a margin-left: of, in this case, 20% or even 22%.

BTW do not specify height for those divs. IE once again gets it wrong by
ignoring your height if the content is higher than that height (quirks mode)
or ignoring height completely ("standards" mode).

Mozilla gets it right. It uses the height you specify. Any content that does
not fit into that height simply flows out the bottom of the div (by default)
possibly overlaying following content. This will occur if a) somebody makes
their font larger, causing word wrap, b) somebody makes their canvas
narowwer, causing your images to wrap:

http://users.bigpond.net.au/rf/test/movie/moz.jpg

Cheers
Richard.

rf wrote:


> "Richard" <anonymous@127.000> wrote in message
> news:...
>> http://1-large-world.com/stargate/movie/moz.jpg
>> Screen shot page.
>>
>> http://1-large-world.com/stargate/movie/tooltip3.html
>> Coded page.
>>
>> The white and black bordered divisions do not "float" left of the red
>> bordered one as they're supposed to.
>> In IE and Opera they do.
>> Any clues as to why?

> In fact it is IE and Opera that are getting this wrong. Mozilla is
> displaying things exactly as they should be.

> Go to the spec and read up on exactly how float works, with particular
> reference to the box model.

> A floated element (div in this case) is totally removed from the flow.
> That means any following divs will be layed out as if the floated div
> were not there. This is what Mozilla is doing correctly. IE incorrectly
> positions subsequent div's to the right of the floated one, particularly
> if you switch on quirks mode, which you have done.

> Once the rest of the page is layed out the floated div is re-inserted to
> the left of where it would have been, at the left edge of its containing
> ancestor (the body element in this case).

> If any *content* from the non floated div's overlap the floated div then
> that *content* is positioned to the right of the floated div and reflowed
> (possibly causing the divs themselves to grow vertically). Note it is the
> *content* that is moved, not the actual div. Thus, we get exactly what
> you are seeing, overlapped borders.

> If you want the white and black divs (and the <hr> for that matter) to
> have their borders aligned to the right of the floated div then you
> should give them a margin-left: of, in this case, 20% or even 22%.

> BTW do not specify height for those divs. IE once again gets it wrong by
> ignoring your height if the content is higher than that height (quirks
> mode) or ignoring height completely ("standards" mode).

> Mozilla gets it right. It uses the height you specify. Any content that
> does not fit into that height simply flows out the bottom of the div (by
> default) possibly overlaying following content. This will occur if a)
> somebody makes their font larger, causing word wrap, b) somebody makes
> their canvas narowwer, causing your images to wrap:

> http://users.bigpond.net.au/rf/test/movie/moz.jpg

> Cheers
> Richard.

I understand what you're saying.
But if the purpose of float, is to allow side by side divisions, and mozilla
is correct, then how can it be correct?
Mozilla has defeated the purpose of float and refuses to recognize it unless
various conditions are met and that's bullshit.
Float, merely acts as a switch. That is it's intended purpose and nothing
more.

"Richard" <anonymous@127.000> wrote in message
news:...
> rf wrote:
>

[post purposely unsnipped]

>
> > "Richard" <anonymous@127.000> wrote in message
> > news:...
> >> http://1-large-world.com/stargate/movie/moz.jpg
> >> Screen shot page.
> >>
> >> http://1-large-world.com/stargate/movie/tooltip3.html
> >> Coded page.
> >>
> >> The white and black bordered divisions do not "float" left of the red
> >> bordered one as they're supposed to.
> >> In IE and Opera they do.
> >> Any clues as to why?
>
> > In fact it is IE and Opera that are getting this wrong. Mozilla is
> > displaying things exactly as they should be.
>
> > Go to the spec and read up on exactly how float works, with particular
> > reference to the box model.
>
> > A floated element (div in this case) is totally removed from the flow.
> > That means any following divs will be layed out as if the floated div
> > were not there. This is what Mozilla is doing correctly. IE incorrectly
> > positions subsequent div's to the right of the floated one,
particularly
> > if you switch on quirks mode, which you have done.
>
> > Once the rest of the page is layed out the floated div is re-inserted
to
> > the left of where it would have been, at the left edge of its
containing
> > ancestor (the body element in this case).
>
> > If any *content* from the non floated div's overlap the floated div
then
> > that *content* is positioned to the right of the floated div and
reflowed
> > (possibly causing the divs themselves to grow vertically). Note it is
the
> > *content* that is moved, not the actual div. Thus, we get exactly what
> > you are seeing, overlapped borders.
>
> > If you want the white and black divs (and the <hr> for that matter) to
> > have their borders aligned to the right of the floated div then you
> > should give them a margin-left: of, in this case, 20% or even 22%.
>
> > BTW do not specify height for those divs. IE once again gets it wrong
by
> > ignoring your height if the content is higher than that height (quirks
> > mode) or ignoring height completely ("standards" mode).
>
> > Mozilla gets it right. It uses the height you specify. Any content that
> > does not fit into that height simply flows out the bottom of the div
(by
> > default) possibly overlaying following content. This will occur if a)
> > somebody makes their font larger, causing word wrap, b) somebody makes
> > their canvas narowwer, causing your images to wrap:
>
> > http://users.bigpond.net.au/rf/test/movie/moz.jpg
>
> > Cheers
> > Richard.
>
> I understand what you're saying.

Good... so far. I was however expecting a 'thankyou'.

> But if the purpose of float, is to allow side by side divisions,

The purpose of float is NOT to allow side by side divisions. The purpose of
float is explained quite clearly in the specs, namely here:
http://www.w3.org/TR/REC-CSS2/visuren.html#floats

It is to remove an element from the flow and then put it back, not affecting
the already flowed element *BUT* affecting their content. This I tried to
clearly explain and even pointed you to the specs, which you seem to
habitually ignore.

Did you or did you not read that chapter of the specs?

> and mozilla
> is correct, then how can it be correct?

Mozilla is correct because it renders your page as per the specs. So, it is
correct, because it is correct.

> Mozilla has defeated the purpose of float

Mozilla renders the HTML and CSS you have supplied as per the specs. So,
Mozilla has not defeated the purpose of float, it has in fact adhered to the
specs and fully implemented the purpose of float.

Your problem is probably that you are using IE as a test browser. IE is
fatally flawed in many respects. The most dramatic of them is that you have
to make an effort to put it into standards mode (which you have *not* done)
otherwise it dies to quirks mode and emulates the incredibly incorrect box
model of IE 5x. This model is so bloody flawed that there are threads
hundreds of posts long about it, if you cared to peruse
http://groups.google.com which you don't.

> and refuses to recognize it

Refuses? No. It fully accepts your HTML and CSS and renders it as per the
specs.

> unless
> various conditions are met

There are no "conditions". Mozilla renders your page as per the specs.

> and that's bullshit.

You can call it bull, cow, pig or even frog ****. It is still how it is.
Mozilla is rendering your page as per the specs. It is your markup that is
causing your problems, not the browser. Can you not see that? No, I suspect
you can not. Your page fails in Mozilla? Ah-ha, Mozilla is a crap browser.
Strawman argument.

> Float, merely acts as a switch.

Where on earth or in the macroscopic universe did you get that from? Float
is not a 'switch'. It is a dramatic alteration to the box model flow for the
floated element. This would have been apparent to you if you had read the
relevant chapter of the specs.

> That is it's intended purpose and nothing
> more.

How typically Richard of you Can't understand it - its wrong - it's
stupid - it's "not it's intended purpose" - you are wrong - everybody is
wrong - the macroscopic unverse is wrong. Well in this case you, Richard,
are wrong. The correct answer is... Oh ****, well, 42

Read the speciation and stop wasting we Hackers time!





OK? Now read them again and this time make sure you understand them.

Cheers
Richard.

Kermit the Frog stuck a mic in rf's face, who said:

>You can call it bull, cow, pig or even frog ****. It is still how it is.

I prefer "horse", myself, although I don't think it's applicable here.

--
- Steve
Not warm and fuzzy feeling.

Steve Greenaway wrote:
> Kermit the Frog stuck a mic in rf's face, who said:
>
>
>>You can call it bull, cow, pig or even frog ****. It is still how it is.
>
>
> I prefer "horse", myself, although I don't think it's applicable here.
>

I prefer "poo".

Chris