Re: Puzzle

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
concepts.

http://www.cl.cam.ac.uk/~jf/StyleTes...dRelative.html

p> Should this text be within the boundary of the container
with the teal background?

No. 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.

<h2>Relative, left: 33%, top: 0</h2
p> Where (horizontally) should this block appear?</p

Same as whitout relative positioning.

<p> Where (vertically) should the text in this block appear?</p

33% of container width from left inner edge of container.

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.

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?

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.

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.

relative

The box's position is calculated according to the
normal flow (this is called the position in normal
flow). Then the box is offset relative to its normal
position. When a box B is relatively positioned, the
position of the following box is calculated as though
B were not offset.

If you both float and relatively position element, it is implemented
mostly as if relative positioning is done after float is taken out of
flow, but it seems that it should be done first. Irrelevat on your
current test page..

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

in comp.infosystems.www.authoring.stylesheets, =?iso-8859-1?q?J=F3n?=
Fairbairn wrote:

Lauri Raittila <lauri (AT) raittila (DOT) cjb.net> writes:

in comp.infosystems.www.authoring.stylesheets, Jón Fairbairn wrote:

I keep reading the definition of CSS2, but am having
difficulty acquiring the precise meaning of certain of the
concepts.

http://www.cl.cam.ac.uk/~jf/StyleTes...dRelative.html

p> Should this text be within the boundary of the container
with the teal background?

No.

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

Same as whitout relative positioning.

<p> Where (vertically) should the text in this block appear?</p

33% of container width from left inner edge of container.

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
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.

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;..."
...stuff...
/div
inline level stuff
div id="b">...
/div
/div

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
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.

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.

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