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:ri ght">blah blah</span>
</div>
The 2nd text does go to the right but the next line. What am I doing
wrong?

TIA.

[Ben C]

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

Gus Richter wrote:

><http://www.w3.org/TR/CSS21/visuren.html#q1 5>
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********@net scape.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