in comp.infosystems.www.authoring.stylesheets, =?iso-8859-
1?q?J=F3n_Fairbairn?= wrote:
> none of these applies. What others are there?
> > I keep reading the definition of CSS2, but am having
> > difficulty acquiring the precise meaning of certain of the
[quoted text clipped - 6 lines]
>
> No.
This is one of the things I find difficult to like.
> IE has bug, as well as about 7.5x Opera, Opera before that gets it
> correct, Opera after that gets it correct only in standards mode.
The full doctype on my page is sufficent to cause Opera to go
into standards mode, isn't it?
> > <h2>Relative, left: 33%, top: 0</h2>
> > <p> Where (horizontally) should this block appear?</p>
[quoted text clipped - 4 lines]
>
> 33% of container width from left inner edge of container.
You seem to have your answers swapped? The left edge should
be 33% of the container width from where it would appear
without positioning, and the top exactly where it would have
appeared.
> > Uncomment this division and it is clear that the
> > float should be contained within the bounds of the
> > teal container.
>
> Correct. There is bug in Gecko. It doesn't like empty elements.
OK
> > Mozilla 1.7.2, firefox 1.0PR and konqueror 3.1.4-7 all
> > display the same way, though not as I would expect.
>
> I am surpriced of konqueror. Does it make diffrence, if
> you use nonempty div for clearing up stuff?
I'll have to check this later; the machine I'm using now
doesn't have konqueror. The browser specific aspects of what
follows concern Opera 7.6
> > Opera 7.54 Final gives a different opinion about the
> > containment question, and MSIE6 on W98 is in a world of
> > its own, although in one respect does what I expect when
> > none of the others does.
>
> Opera 7.6 preview 3 gets everything correctly.
I've just looked at the page with 7.60 p3, and I'm not
convinced. I'm willing to accept that the bottom of an
overlong float should poke out of the container (if I can
find the right piece of verbiage in the docs), but I don't
see how the positioning of the inner block can be right.
If you replace "left: 33%" with "left: 0", the text in
#inner appears below the float. Now, the bits I've read
about relative positioning lead me to understand that the
effect should be to format the block as if it were not
positioned, and then move it by the amount specified. But
Opera changes the shape of the block after it has moved it.
One of the difficulties is that rather than making #inner
flow past the float, it is the content of #inner that does
the flowing.
> > For the containment question, I see this (REC-CSS2, 11.1):
>
> > none of these applies. What others are there?
>
> float is taken out of normal flow. So it is not really
> content of said block.
I can accept that, as far as containment is concerned.
> > relative
> >
[quoted text clipped - 10 lines]
> should be done first. Irrelevat on your current test
> page..
Yes. I'm only relatively positioning a normal block.
The problem I'm having is in building up a picture of what
the formatting of the content of a block depends on. It
seems reasonable to expect that it will depend on either the
width, height (, padding &c) specified for the block (which
may themselves be dependent on the container, and where not
specified, the intrinsic dimensions of the content.
It's much less clear that it need be the case (in future
stylesheet languages) that it should also depend on such
things as whether there is anything floating in the
containing block. Certainly the /position/ depends on such
things, but is it really necessary that the flow inside the
block be disrupted that way?
In
<div id="a">
<div id="f" style="float: left;...">
...stuff...
</div>
inline level stuff
<div id="b">...
</div>
</div>
The "inline level stuff" will flow around to the right of
"f". Now, since "b" doesn't have "clear" set, I would expect
that (assuming it's small enough and that "inline level
stuff" doesn't take us past the float) "b" should also
appear /as an entire block/ to the right of "f". (If "b" had
"display: inline" it would be different).
What happens in the present scheme appears to be that "b" is
positioned below "inline level stuff", but instead of being
positioned to the right of "f", it overlays it, and its
padding-left is replaced by max(padding-left(b),width(f)) to
leave room for "f". I would expect this to be the source of
much confusion, as well as requiring too much knowledge
about the environment when coding inner blocks.

Signature
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
Lauri Raittila - 26 Nov 2004 19:39 GMT
in comp.infosystems.www.authoring.stylesheets, =?iso-8859-1?q?J=F3n?=
Fairbairn wrote:
> > > I keep reading the definition of CSS2, but am having
> > > difficulty acquiring the precise meaning of certain of the
[quoted text clipped - 8 lines]
>
> This is one of the things I find difficult to like.
But that is *very* clear in spec.
> > IE has bug, as well as about 7.5x Opera, Opera before that gets it
> > correct, Opera after that gets it correct only in standards mode.
s/that/Opera 7.5x/g
> The full doctype on my page is sufficent to cause Opera to go
> into standards mode, isn't it?
Yes, but there is bug on 7.5x series. Anything newer and older should
render stuff correctly, newer only if in standards mode.
> > > <h2>Relative, left: 33%, top: 0</h2>
> > > <p> Where (horizontally) should this block appear?</p>
[quoted text clipped - 6 lines]
>
> You seem to have your answers swapped?
Yes. Somehow I always think first vertical and then horizontal
positioning...
> > > Mozilla 1.7.2, firefox 1.0PR and konqueror 3.1.4-7 all
> > > display the same way, though not as I would expect.
> > > Opera 7.54 Final gives a different opinion about the
> > > containment question, and MSIE6 on W98 is in a world of
[quoted text clipped - 8 lines]
> find the right piece of verbiage in the docs), but I don't
> see how the positioning of the inner block can be right.
It is. Floats only have effect on text lines, not block elements. As your
elelement is about same size as float, text lines are moved down untill
there is enaugh space.
> If you replace "left: 33%" with "left: 0", the text in
> #inner appears below the float.
As it does whitout position:relative and left:0 too.
> Now, the bits I've read
> about relative positioning lead me to understand that the
> effect should be to format the block as if it were not
> positioned, and then move it by the amount specified.
Yes.
> But
> Opera changes the shape of the block after it has moved it.
The block shape is not relevant, it's top left corner is.
> One of the difficulties is that rather than making #inner
> flow past the float, it is the content of #inner that does
> the flowing.
That is because your #inner is too narrow to have text beside float.
There is about 1ex space between border of float and border of #inner.
Your text don't fit in that space.
> The problem I'm having is in building up a picture of what
> the formatting of the content of a block depends on. It
> seems reasonable to expect that it will depend on either the
> width, height (, padding &c) specified for the block (which
> may themselves be dependent on the container, and where not
> specified, the intrinsic dimensions of the content.
Yes.
> It's much less clear that it need be the case (in future
> stylesheet languages) that it should also depend on such
> things as whether there is anything floating in the
> containing block.
Well, that has effect on text line lenghts, so it has effect on number of
text lines as well.
How the hell you think float would work, if it would not affect on
rendering something? It would be same as absolute positioning then.
> Certainly the /position/ depends on such
> things, but is it really necessary that the flow inside the
> block be disrupted that way?
How the hell would you do it then? The whole point of float is that.
> <div id="a">
> <div id="f" style="float: left;...">
[quoted text clipped - 7 lines]
> The "inline level stuff" will flow around to the right of
> "f".
Right.
> Now, since "b" doesn't have "clear" set, I would expect
> that (assuming it's small enough and that "inline level
> stuff" doesn't take us past the float) "b" should also
> appear /as an entire block/ to the right of "f". (If "b" had
> "display: inline" it would be different).
No. That would not be good. If you want that use display:table for .b
And more importantly, that was not the way it is defined.
> What happens in the present scheme appears to be that "b" is
> positioned below "inline level stuff", but instead of being
[quoted text clipped - 3 lines]
> much confusion, as well as requiring too much knowledge
> about the environment when coding inner blocks.
That is exactly same method used for floating stuff since NN1 and maybe
before. It has worked just fine. It would have made no sence to change
definition of float to something more complicated.
I think your problem is that you don't think float as float but some way
to archive layout which would be better done using CSS tables.

Signature
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>