float:right goes to next line

[ashkaan57]

Hi,
I am trying to put text on left and right side of the page and used:
<div>
<span>blah blah</span>
<span style="float:right">blah blah</span>
</div>
The 2nd text does go to the right but the next line. What am I doing
wrong?

TIA.

[Rik]

as*******@hotmail.com wrote:

Hi,
I am trying to put text on left and right side of the page and used:
<div>
<span>blah blah</span>
<span style="float:right">blah blah</span>
</div>
The 2nd text does go to the right but the next line. What am I doing
wrong?

Nothing really. As far as I know it _should_ work, but doesn't.
Browser bug. If you change it to this it renders OK:
<div>
<span style="float:right">blah blah</span>
<span>blah blah</span>
</div>
--
Rik Wasmus

[Ben C]

On 2007-01-12, Rik <lu************@hotmail.comwrote:

as*******@hotmail.com wrote:

>Hi,
I am trying to put text on left and right side of the page and used:
<div>
<span>blah blah</span>
<span style="float:right">blah blah</span>
</div>
The 2nd text does go to the right but the next line. What am I doing
wrong?

Nothing really. As far as I know it _should_ work, but doesn't.
Browser bug. If you change it to this it renders OK:
<div>
<span style="float:right">blah blah</span>
<span>blah blah</span>
</div>

Yes, this is a known bug in Firefox. Unless the float comes first thing,
it goes one line down, which is contrary to the spec.

But actually simpler in many ways.

In the case where there are a few words followed by a float, the browser
doesn't know which line the float should start on until it has a go at
laying out the words (the words might take up two and half lines or so).
Then it gets to the float, and puts that in. But now that the float's in
the way, the words on that line might not all fit any more-- the line
might need to be broken. This could result in the word preceding the
float in the content ending up below it, which is excluded by the rules,
so the browser may have to restart the line, this time putting the float
on the next line.

If it puts the float on the next line anyway (unless it's right at the
start), its job is a lot easier.

[ashkaan57]

Rik wrote:

as*******@hotmail.com wrote:

Hi,
I am trying to put text on left and right side of the page and used:
<div>
<span>blah blah</span>
<span style="float:right">blah blah</span>
</div>
The 2nd text does go to the right but the next line. What am I doing
wrong?

Nothing really. As far as I know it _should_ work, but doesn't.
Browser bug. If you change it to this it renders OK:
<div>
<span style="float:right">blah blah</span>
<span>blah blah</span>
</div>
--
Rik Wasmus

Thanks Rick. Putting the float:right first fixed the problem.
By the way, I had this problem in IE7 as well as FF.

[Gus Richter]

Ben C wrote:

On 2007-01-12, Rik <lu************@hotmail.comwrote:

>as*******@hotmail.com wrote:

>>Hi,
I am trying to put text on left and right side of the page and used:
<div>
<span>blah blah</span>
<span style="float:right">blah blah</span>
</div>
The 2nd text does go to the right but the next line. What am I doing
wrong?

Nothing really. As far as I know it _should_ work, but doesn't.
Browser bug.

I don't think that it's a bug at all and that Fx, Opera and even IE
render it identically as they should according to the markup.

>If you change it to this it renders OK:
<div>
<span style="float:right">blah blah</span>
<span>blah blah</span>
</div>

This is the way to get it to render as you want it to.

Yes, this is a known bug in Firefox. Unless the float comes first thing,
it goes one line down, which is contrary to the spec.

I don't believe that it is a bug. Please state the Bug# and/or any
reference to it. I believe that the browsers all (identically) render in
accordance to the specs. Here is a detailed, referenced explanation of
the OP's markup:

<http://www.w3.org/TR/CSS21/visuren.html#q5>
9.2.1 Block-level elements and block boxes
Block-level elements (the DIV wrapper in this case) generate a principal
block box that contains either only block boxes or only inline boxes.
The principal block box establishes the containing block for descendant
boxes and generated content and is also the box involved in any
positioning scheme. Principal block boxes participate in a block
formatting context.

<http://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level>
9.2.1.1 Anonymous block boxes
How anonymous block boxes may spring into existence around anonymous
content.
The DIV appears to have both inline content and block content. To make
it easier to define the formatting, we assume that there is an anonymous
block box around "Some [anonymous] text". In other words: if a block box
has another block box inside it, then we force it to have only block
boxes inside it.

<http://www.w3.org/TR/CSS21/visuren.html#q15>
9.4.1 Block formatting contexts
Floats establish new block formatting contexts.
In a block formatting context, boxes are laid out one after the other,
vertically, beginning at the top of a containing block. The vertical
distance between two sibling boxes is determined by the 'margin'
properties. Vertical margins between adjacent block boxes in a block
formatting context collapse.

Explaining the behavior:
1. The principal block box (the div container) may contain either only
block boxes or only inline boxes.
2. If a block box has another block box inside it, then we force it to
have only block boxes inside it.
3. The principal block box (the div container) contains a floated SPAN
which establishes a new block formatting context.
4. Since there is a block in the container, the in-flow SPAN is forced
to have an assumed anonymous block box around it.
5. The in-flow SPAN, essentially a block now, is presented.
6. The floated SPAN, essentially a block now, is presented (laid out
after the other, vertically, floated right on a new line).
7. The anonymous text (also with an assumed anonymous block box around
it) flows up between the two SPANs (as long as it fits, which it does
here) as high as it can, which here is the same as that of the in-flow SPAN.

--
Gus

[Gus Richter]

Gus Richter wrote:

7. The anonymous text (also with an assumed anonymous block box around
it) flows up between the two SPANs (as long as it fits, which it does
here) as high as it can, which here is the same as that of the in-flow
SPAN.

Ignore item 7. since this was something not included in the OP's
example, but something extra left over from one of my tests as in:

<div>
<span>blah blah</span>
<span style="float:right">blah blah</span>
Some anonymous text.
</div>

--
Gus

[Ben C]

On 2007-01-13, Gus Richter <gu********@netscape.netwrote:

Ben C wrote:

>On 2007-01-12, Rik <lu************@hotmail.comwrote:

>>as*******@hotmail.com wrote:
Hi,
I am trying to put text on left and right side of the page and used:
<div>
<span>blah blah</span>
<span style="float:right">blah blah</span>
</div>
The 2nd text does go to the right but the next line. What am I doing
wrong?
Nothing really. As far as I know it _should_ work, but doesn't.
Browser bug.

I don't think that it's a bug at all and that Fx, Opera and even IE
render it identically as they should according to the markup.

Opera and FF don't render it identically. Opera and Konqueror both get
it right, FF wrong. I haven't tried IE.

Try the OP's example, make sure there's enough room on the first line
for the first "blah blah" and the float. In that case, the top of the
float should be aligned with the top of the line box. FF aligns its top
with the top of the next line (although I am still on version 1.5--
maybe they fixed this in version 2?)

The relevant part of the spec is in 9.5 (CSS 2.1), second paragraph,
which you left out of the sections you posted.

"If there’s a line box, the top of the floated box is aligned with
the top of the current line box."

[snip]

>Yes, this is a known bug in Firefox. Unless the float comes first thing,
it goes one line down, which is contrary to the spec.

I don't believe that it is a bug. Please state the Bug# and/or any
reference to it.

I think someone in one of c.i.w.a.[hs] or alt.html posted a link that
referenced the bug on some Mozilla page somewhere, so you could try the
Google groups search.

[Ben C]

On 2007-01-13, Gus Richter <gu********@netscape.netwrote:

Ben C wrote:

>On 2007-01-12, Rik <lu************@hotmail.comwrote:

>>as*******@hotmail.com wrote:
Hi,
I am trying to put text on left and right side of the page and used:
<div>
<span>blah blah</span>
<span style="float:right">blah blah</span>
</div>
The 2nd text does go to the right but the next line. What am I doing
wrong?

[snip]

Sorry, missed this bit.

Explaining the behavior:
1. The principal block box (the div container) may contain either only
block boxes or only inline boxes.

Correct.

2. If a block box has another block box inside it, then we force it to
have only block boxes inside it.

Well, this is a bit different though. What we have is a block box with a
float in it. Although a float is display: block, that's really all about
how you lay out what's _inside_ the float, not about how the float fits
into its surroundings.

Float placing is something that goes hand-in-hand with inline-box
layout.

3. The principal block box (the div container) contains a floated SPAN
which establishes a new block formatting context.

Correct.

4. Since there is a block in the container, the in-flow SPAN is forced
to have an assumed anonymous block box around it.

No, there's definitely not a block box around inline content either side
of a float-- the text has to flow around the float.

I say "definitely", but this is really a matter of interpretation, so
I'm tempted not to argue. But I can't see much sense in the idea that
text flowing around a float is split into two anonymous blocks either
side of the float.

[Eric Lindsay]

In article <_Z******************************@golden.net>,
Gus Richter <gu********@netscape.netwrote:

Ben C wrote:

On 2007-01-12, Rik <lu************@hotmail.comwrote:

as*******@hotmail.com wrote:
Hi,
I am trying to put text on left and right side of the page and used:
<div>
<span>blah blah</span>
<span style="float:right">blah blah</span>
</div>
The 2nd text does go to the right but the next line. What am I doing
wrong?
Nothing really. As far as I know it _should_ work, but doesn't.
Browser bug.

I don't think that it's a bug at all and that Fx, Opera and even IE
render it identically as they should according to the markup.

When I tested about a year ago, Opera and Safari got it "right", in that
the floated element stayed on the same line, as I intended it. Firefox
and IE got it "wrong" from my point of view, by putting the element on
the next line.

>

If you change it to this it renders OK:
<div>
<span style="float:right">blah blah</span>
<span>blah blah</span>
</div>

This is the way to get it to render as you want it to.

My test page for something similar to this has been up for a while at
http://www.ericlindsay.com/palmtop/palmnote.htm
and the right hand item in the header and footer are on the same line in
Safari and Opera.

I never did understand why this caused problems with Firefox, so I am
delighted this thread appeared.

Yes, this is a known bug in Firefox. Unless the float comes first thing,
it goes one line down, which is contrary to the spec.

Thanks for your explanation of what you believe should be happening. I
am putting a bunch of LI block elements inline, and selecting one of
these elements to be floated right. So within the UL block element, all
the LI were now declared inline, and the UL block contained only LI
elements. Since all the other identically styled LI block elements stay
inline, I couldn't understand why one of them should decide it was
really still a block. Especially since two browsers worked the way I
expected.

<http://www.w3.org/TR/CSS21/visuren.html#q15>
9.4.1 Block formatting contexts
Floats establish new block formatting contexts.
In a block formatting context, boxes are laid out one after the other,
vertically, beginning at the top of a containing block. The vertical
distance between two sibling boxes is determined by the 'margin'
properties. Vertical margins between adjacent block boxes in a block
formatting context collapse.

Explaining the behavior:
1. The principal block box (the div container) may contain either only
block boxes or only inline boxes.
2. If a block box has another block box inside it, then we force it to
have only block boxes inside it.
3. The principal block box (the div container) contains a floated SPAN
which establishes a new block formatting context.
4. Since there is a block in the container, the in-flow SPAN is forced
to have an assumed anonymous block box around it.
5. The in-flow SPAN, essentially a block now, is presented.
6. The floated SPAN, essentially a block now, is presented (laid out
after the other, vertically, floated right on a new line).
7. The anonymous text (also with an assumed anonymous block box around
it) flows up between the two SPANs (as long as it fits, which it does
here) as high as it can, which here is the same as that of the in-flow SPAN.

After reading your fine explanation, I think I am still confused as to
why different browsers made different decisions about this.

The way I read 9.4.1 and your explanation is that my floated right LI
becomes a new block pulled out of normal display. If the floated element
is first, it is positioned at the right. However there is then still
room for the other inline LI to be positioned prior to reaching the new
block. if the floated LI is not first, then some LI elements are already
positioned within the UL containing block. So the floated LI must go
below them. It would seem that some browsers regard turning a floated
element into a block is overridden if the element was styled as display
inline. Doing so seemed reasonable to me, which is why I expected it to
work.

--
http://www.ericlindsay.com

[Gus Richter]

Ben C wrote:

>
Opera and FF don't render it identically. Opera and Konqueror both get
it right, FF wrong. I haven't tried IE.

Try the OP's example, make sure there's enough room on the first line
for the first "blah blah" and the float. In that case, the top of the
float should be aligned with the top of the line box. FF aligns its top
with the top of the next line (although I am still on version 1.5--
maybe they fixed this in version 2?)

Sadly I did not apply a Strict Doctype so my results were Quirky (Fx,
Opera, IE6, IE7 all identical - line spaced). No idea why Opera renders
this differently in Quirk Mode.
With a Strict DTD Doctype applied, (Fx, IE6, IE7 all identical - line
spaced. Opera odd man out - on the same line). I'm on the side of Fx and
IE on this (so far).
No idea on any other browsers' rendering.

The relevant part of the spec is in 9.5 (CSS 2.1), second paragraph,
which you left out of the sections you posted.

"If there’s a line box, the top of the floated box is aligned with
the top of the current line box."

<http://www.w3.org/TR/CSS21/visuren.html#line-box>
9.4.2 Inline formatting context
This defines a "line box" in an inline formatting context which I
believe it isn't. In reading this section, I believe the OP's example to
be in a block formatting context.

--
Gus

[Gus Richter]

Ben C wrote:

>2. If a block box has another block box inside it, then we force it to
have only block boxes inside it.

Well, this is a bit different though. What we have is a block box with a
float in it. Although a float is display: block, that's really all about
how you lay out what's _inside_ the float, not about how the float fits
into its surroundings.

..3 says that the float is a block, so 2. says that if there is a block,
all are blocks.

Float placing is something that goes hand-in-hand with inline-box
layout.

<http://www.w3.org/TR/CSS21/visuren.html#line-box>
9.4.2 Inline formatting context
This defines a "line box" in an inline formatting context which I
believe it isn't. As I explained, I believe the OP's example to be in a
block formatting context.

>4. Since there is a block in the container, the in-flow SPAN is forced
to have an assumed anonymous block box around it.

No, there's definitely not a block box around inline content either side
of a float-- the text has to flow around the float.

<http://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level>
9.2.1.1 Anonymous block boxes
How anonymous block boxes may spring into existence around anonymous
content.
The DIV appears to have both inline content and block content. To make
it easier to define the formatting, we assume that there is an anonymous
block box around "Some [anonymous] text". In other words: if a block box
has another block box inside it, then we force it to have only block
boxes inside it.

I say "definitely", but this is really a matter of interpretation, so
I'm tempted not to argue. But I can't see much sense in the idea that
text flowing around a float is split into two anonymous blocks either
side of the float.

I very much appreciate your arguments, since I also have my doubts. I
make my case as I understand it and am wearing my full body armor for
this newsgroup. I look forward to your further counter-points as I, in
the meanwhile, rehash the material.

7. containing my added anonymous text to the OP's example, I see as
another anonymous block box containing Line Boxes.
<http://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level>
<http://www.w3.org/TR/CSS21/visuren.html#q15>

The Line Boxes participate in an inline formatting context:
<http://www.w3.org/TR/CSS21/visuren.html#line-box>
The Line Box is the same width as the container, but the floated box
will shorten the container until the float is cleared and the content
(line boxes) will (shrink)wrap around the float.

--
Gus

[Ben C]

On 2007-01-14, Gus Richter <gu********@netscape.netwrote:

Ben C wrote:

>>2. If a block box has another block box inside it, then we force it to
have only block boxes inside it.

Well, this is a bit different though. What we have is a block box with a
float in it. Although a float is display: block, that's really all about
how you lay out what's _inside_ the float, not about how the float fits
into its surroundings.

.3 says that the float is a block, so 2. says that if there is a block,
all are blocks.

Your conclusion is logical, and supported by the spec. And works just as
well: it doesn't really matter what block boxes we think of the inlines
either side of a float as in (i.e. whether we subdivide into anonymous
blocks or not), because they have to flow around the float anyway.

[snip]

I very much appreciate your arguments, since I also have my doubts. I
make my case as I understand it and am wearing my full body armor for
this newsgroup. I look forward to your further counter-points as I, in
the meanwhile, rehash the material.

Your interpretation makes sense. I think we're now agreed that in the
OP's example, the float should have been aligned to the top of the first
line-- it turned out to be a quirks mode issue.

Although your interpretation was intended to explain as correct the
behaviour that we're now agreed is wrong, with small modifications the
interpretation still works perfectly well.

You can say that when a float is encountered, we put an anonymous block
around the inline contents preceding it, in the normal way, but that the
inline contents of that anonymous block have to be flowed around the
float. Inline contents of all blocks (anonymous or not) have to be
flowed around floats, so it all just works.

Floats primarily interact with inline boxes-- you have to fit the floats
and inline boxes around each other in accordance with the rules. This is
what has led me to the view that "floats-and-inlines" are what you lay
out in a block box, together, and on that basis there is no reason for
an implementation to put anonymous blocks around inline sequences either
side of a float. But it wouldn't hurt anyone if it did, and that _is_
what the spec says.

[Ben C]

On 2007-01-14, Ben C <sp******@spam.eggswrote:

On 2007-01-14, Gus Richter <gu********@netscape.netwrote:

>Ben C wrote:

>>>2. If a block box has another block box inside it, then we force it to
have only block boxes inside it.

Well, this is a bit different though. What we have is a block box with a
float in it. Although a float is display: block, that's really all about
how you lay out what's _inside_ the float, not about how the float fits
into its surroundings.

.3 says that the float is a block, so 2. says that if there is a block,
all are blocks.

Your conclusion is logical, and supported by the spec. And works just as
well: it doesn't really matter what block boxes we think of the inlines
either side of a float as in (i.e. whether we subdivide into anonymous
blocks or not), because they have to flow around the float anyway.

[snip]

Floats primarily interact with inline boxes-- you have to fit the floats
and inline boxes around each other in accordance with the rules. This is
what has led me to the view that "floats-and-inlines" are what you lay
out in a block box, together, and on that basis there is no reason for
an implementation to put anonymous blocks around inline sequences either
side of a float. But it wouldn't hurt anyone if it did, and that _is_
what the spec says.

I'm going to refine this: Gus's interpretation that you get anonymous
blocks to wrap inline content either side of a float is the right one
(and mine is the one that "also works", "doesn't hurt anyone", etc.).

In my own mind, I'm putting an anonymous block around a float on its own
between two blocks, because I'm having it that a float originates in an
inline context.

Either interpretation works-- the effect on the output is exactly
equivalent, except for where the anonymous blocks are, but you can't see
them anyway.

But Gus's is more consistent with the spec, and I don't want to mislead
anyone.

To clarify again: all this is orthogonal to the OP's original question,
about where a float is positioned vertically, and the answer is it
should be aligned to the top of the current line box, as specified in
CSS 2.1 9.5, but that in FF it isn't.

[Gus Richter]

Ben C wrote:

>
To clarify again: all this is orthogonal to the OP's original question,
about where a float is positioned vertically, and the answer is it
should be aligned to the top of the current line box, as specified in
CSS 2.1 9.5, but that in FF it isn't.

I hate to be a spoil sport, but item 6. in my "Explaining the Behavior"
listing in my first posting still holds. This is not to be confused with
7. which is not part of the OP's original example, but my added
anonymous text after the floated SPAN.

6. The floated SPAN, essentially a block now, is presented (laid out
after the other, vertically, floated right on a new line).

<http://www.w3.org/TR/CSS21/visuren.html#q15>
9.4.1 Block formatting contexts
Floats establish new block formatting contexts.
In a block formatting context, boxes are laid out one after the other,
vertically, beginning at the top of a containing block.

Yes, 7. (anonymous text after the floated SPAN) aligns to the top of the
line box, but 6. (floated SPAN), in a block context and following 5.
(the in-flow SPAN, essentially a block now), causes 6. (floated SPAN) to
be laid out vertically, on a new line, below 5. and that's why I said
that even in Strict Mode, I believe Fx and IE are correct and Opera is
wrong.

--
Gus

[Ben C]

On 2007-01-14, Gus Richter <gu********@netscape.netwrote:

Ben C wrote:

>>
To clarify again: all this is orthogonal to the OP's original question,
about where a float is positioned vertically, and the answer is it
should be aligned to the top of the current line box, as specified in
CSS 2.1 9.5, but that in FF it isn't.

I hate to be a spoil sport, but item 6. in my "Explaining the Behavior"
listing in my first posting still holds. This is not to be confused with
7. which is not part of the OP's original example, but my added
anonymous text after the floated SPAN.

6. The floated SPAN, essentially a block now, is presented (laid out
after the other, vertically, floated right on a new line).

<http://www.w3.org/TR/CSS21/visuren.html#q15>
9.4.1 Block formatting contexts
Floats establish new block formatting contexts.
In a block formatting context, boxes are laid out one after the other,
vertically, beginning at the top of a containing block.

Yes, 7. (anonymous text after the floated SPAN) aligns to the top of the
line box, but 6. (floated SPAN), in a block context and following 5.
(the in-flow SPAN, essentially a block now), causes 6. (floated SPAN) to
be laid out vertically, on a new line, below 5. and that's why I said
that even in Strict Mode, I believe Fx and IE are correct and Opera is
wrong.

All this is valid.

There is still a slight problem with the wording of 9.5 though:

"If there's a line box, the top of the floated box is aligned with
the top of the current line box."

It says "_If_ there's a line box". On your interpretation, there will
never be a line box, because the (implicitly block-level) float will
start a new block box.

[Gus Richter]

Gus Richter wrote:

<http://www.w3.org/TR/CSS21/visuren.html#q15>
9.4.1 Block formatting contexts
Floats establish new block formatting contexts.
In a block formatting context, boxes are laid out one after the other,
vertically, beginning at the top of a containing block.

Yes, 7. (anonymous text after the floated SPAN) aligns to the top of the
line box, but 6. (floated SPAN), in a block context and following 5.
(the in-flow SPAN, essentially a block now), causes 6. (floated SPAN) to
be laid out vertically, on a new line, below 5. and that's why I said
that even in Strict Mode, I believe Fx and IE are correct and Opera is
wrong.

OK, I see my mistake now. I kept skipping over:

"In a block formatting context, boxes are laid out one after the other,
vertically, _beginning at the top of a containing block_."

*You were right and I was wrong*. I agree with you now in that Opera is
right and Fx and IE are wrong.

3. The principal block box (the div container) contains a floated SPAN
which establishes a new block formatting _context_.

Which somewhere in the thread you correctly point out is regarding the
"content" and not the float itself. I'll have to check on how I
countered that.

6. is also incorrect. The float being out of the normal flow, should
align to the top of the container.

I hope that I've not gone in circles. I have to walk away from this for
a day or two and then look at it again. Thank you, because this exchange
has been very helpful and informative (I hope). Thought provoking for sure.

--
Gus

[Gus Richter]

Eric Lindsay wrote:

>
After reading your fine explanation, I think I am still confused as to
why different browsers made different decisions about this.

Thank you for the kind words. I feared the worst and therefore hesitated
to comment in this newsgroup. I have looked at your page and believe it
to be an actual live example of the problem.

If you have followed the discussion, you will have noticed that I was
unsure of my reasoning and in fact am still unsure of my sudden reversed
position.

I do have to walk away from this for a while and look at this afresh
then. Perhaps new thinkers will voice their opinions on this in the
meanwhile.

Oh, and I suppose that the different browser developers also had
problems interpreting the muddled morass on the subject?

--
Gus

[Ben C]

On 2007-01-14, Gus Richter <gu********@netscape.netwrote:

Eric Lindsay wrote:

>>
After reading your fine explanation, I think I am still confused as to
why different browsers made different decisions about this.

[snip]

Oh, and I suppose that the different browser developers also had
problems interpreting the muddled morass on the subject?

Yes, I can confirm that at least some of them did.

What IE7 and FF are doing (float starts on next line) is also quite a
bit simpler and more efficient to implement, so I'm hoping we can find
some way to justify it.

[Alex]

When I was trying to figure out if browsers work as CSS say, I have
found suitable answer in these words:

9.5 Floats
...
Any content in the current line before a floated box is reflowed in the
first available line on the other side of the float. In other words, if
inline boxes are placed on the line before a left float is encountered
that fits in the remaining line box space, the left float is placed on
that line, aligned with the top of the line box, and then the inline
boxes already on the line are moved accordingly to the right of the
float
....

This is why I guess browsers (at least mentioned) render it wrong.

But one interesting paragraph more.

9.5.1

6. The outer top [p. 100] of an element's floating box may not be
higher than the top of any line-box [p. 126] containing a box generated
by an element earlier in the source document.

I understand it this way. If we had S1 S2 LF S3, where Sx stands for
span element, and LF to left-floated element, than it can be rendered
as:

.... S1
LF S2
S3 ...

LF S1 S2
S3

All depends on the container box width. But cann't this way:

LF S1
S2 S3

Because the "top" of the line box containing S2 ("an element earlier in
document") is below the "outer top" of the "floating box".
- Alex.

[Ben C]

On 2007-01-14, Alex <ac******@gmail.comwrote:
[snip]

I understand it this way. If we had S1 S2 LF S3, where Sx stands for
span element, and LF to left-floated element, than it can be rendered
as:

... S1
LF S2
S3 ...

LF S1 S2
S3

All depends on the container box width.

Firefox always does the first of the two alternatives, regardless of the
container box width.

But cann't this way:

LF S1
S2 S3

Because the "top" of the line box containing S2 ("an element earlier in
document") is below the "outer top" of the "floating box".

Yes, that would definitely be a bug.

[Ben C]

On 2007-01-14, Gus Richter <gu********@netscape.netwrote:

Gus Richter wrote:

><http://www.w3.org/TR/CSS21/visuren.html#q15>
9.4.1 Block formatting contexts
Floats establish new block formatting contexts.
In a block formatting context, boxes are laid out one after the other,
vertically, beginning at the top of a containing block.

Yes, 7. (anonymous text after the floated SPAN) aligns to the top of the
line box, but 6. (floated SPAN), in a block context and following 5.
(the in-flow SPAN, essentially a block now), causes 6. (floated SPAN) to
be laid out vertically, on a new line, below 5. and that's why I said
that even in Strict Mode, I believe Fx and IE are correct and Opera is
wrong.

OK, I see my mistake now. I kept skipping over:

"In a block formatting context, boxes are laid out one after the other,
vertically, _beginning at the top of a containing block_."

*You were right and I was wrong*. I agree with you now in that Opera is
right and Fx and IE are wrong.

All the same, what normally happens when it's time to start a new block
box is the new block box starts below the old one.

But if the new block box is a floating block, it's aligned with the top
of the current line in the existing block box. Then the current line has
to be reformatted around the float (which may mean repositioning the
float if the line breaks-- that's why the rule is annoying).

3. The principal block box (the div container) contains a floated SPAN
which establishes a new block formatting _context_.

Which somewhere in the thread you correctly point out is regarding the
"content" and not the float itself. I'll have to check on how I
countered that.

Yes.

In passing note that "block formatting context" is not the same as
"block box". All block formatting contexts are also block boxes, but not
all block boxes are block formatting contexts.

I hope that I've not gone in circles.

If you have you haven't been the only one :)

I have to walk away from this for a day or two and then look at it
again. Thank you, because this exchange has been very helpful and
informative (I hope). Thought provoking for sure.

Certainly.

[Alex]

Just to be absolutelly correct, Firefox do it this way:

S1 S2
LF

Firefox always does the first of the two alternatives, regardless
of the container box width.

[Eric Lindsay]

In article <sv******************************@golden.net>,
Gus Richter <gu********@netscape.netwrote:

Eric Lindsay wrote:

http://www.ericlindsay.com/palmtop/palmnote.htm
After reading your fine explanation, I think I am still confused as to
why different browsers made different decisions about this.

Thank you for the kind words. I feared the worst and therefore hesitated
to comment in this newsgroup. I have looked at your page and believe it
to be an actual live example of the problem.

I have hesitated to use anything like my example in most of my pages
because I did not understand why I was having the positioning problems I
encountered. This discussion is the first that gave me any appreciation
of what was happening. So I can finally get back to experimenting with
that page. Thank you very much.

>
If you have followed the discussion, you will have noticed that I was
unsure of my reasoning and in fact am still unsure of my sudden reversed
position.

Yes. Like you, I have changed my mind several times about what was the
intended effect of the CSS specification, and which browser was right. I
have returned to my first view, that Opera and Safari have it right, and
IE and Firefox have it wrong.

Oh, and I suppose that the different browser developers also had
problems interpreting the muddled morass on the subject?

On the side of dealing with it, it seems unlikely that IE and Firefox
will change to the Opera and Safari view. Especially when coding it
their way may be easier. So pragmatically, from now on I will put the
right floated LI element as the first LI element in a UL.

It does seem to me this would make CMS code a little cleaner, when I get
around to writing it. It also means that instead of styling the LI
pointing to the current location by means of an ID or CLASS, I can
remove the superfluous ID or CLASS, and instead use the equivalent of
the :first-child pseudo-selector. As I doubt :first-child is well
supported, I will probably try UL + LI to use the adjacent element
selector within the navigation (although I think IE5 and 6 will fail on
that).

(As an aside, my header and footer already place vertical separators and
arrows using :first-child and :before pseudo selectors. This gets them
out of my HTML. IE6 and IE7 ignore them. As the failure is cosmetic, I
will continue to use them. )

--
http://www.ericlindsay.com