prinicpal block boxes (css 2.1)

[dave8421]

Hi,

I'm a bit confused about the definition about "Prinicpal Block Boxes"
in CSS 2.1 draft specification.
( http://www.w3.org/TR/2006/WD-CSS21-20061106 )

>From the spec:

<pre>
9.2.1 Block-level elements and block 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
</pre>

The part "is also the box invovled in any positionnig scheme" seems to
contradict the definition of containing block, unless they mean that it
is indirectly involved?

<pre>
10.1 Definition of "containing block"
(Point 4)
If the element has 'position: absolute', the containing block is
established by the nearest ancestor with a 'position' of 'absolute',
'relative' or 'fixed', in the following way:
In the case that the ancestor is inline-level, the containing block
depends on the 'direction' property of the ancestor:
If the 'direction' is 'ltr', the top and left of the containing block
are the top and left padding edges of the first box generated by the
ancestor, and the bottom and right are the bottom and right padding
edges of the last box of the ancestor.
</pre>

So in the case the ancestor is inline, the containing block is
determined by the boxes it generates, and not directly from a prinicpal
block box

Any help appreciated in clearing this up .. .I'm sure I'm missing
something

[Ben C]

On 2007-01-25, da******@hotmail.com <da******@hotmail.comwrote:

Hi,

I'm a bit confused about the definition about "Prinicpal Block Boxes"
in CSS 2.1 draft specification.
( http://www.w3.org/TR/2006/WD-CSS21-20061106 )

>>From the spec:

<pre>
9.2.1 Block-level elements and block 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
</pre>

The part "is also the box invovled in any positionnig scheme" seems to
contradict the definition of containing block, unless they mean that it
is indirectly involved?

I don't understand where there's a contradiction here.

I assume by "the box involved in any positioning scheme" they mean the
box whose position is adjusted by the top, left, bottom and right
properties if it's position: fixed, relative or absolute.

But an absolutely positioned box also establishes a containing block for
its own descendents.

><pre>
10.1 Definition of "containing block"
(Point 4)
If the element has 'position: absolute', the containing block is
established by the nearest ancestor with a 'position' of 'absolute',
'relative' or 'fixed', in the following way:
In the case that the ancestor is inline-level, the containing block
depends on the 'direction' property of the ancestor:
If the 'direction' is 'ltr', the top and left of the containing block
are the top and left padding edges of the first box generated by the
ancestor, and the bottom and right are the bottom and right padding
edges of the last box of the ancestor.
</pre>

So in the case the ancestor is inline, the containing block is
determined by the boxes it [the ancestor] generates, and not directly
from a prinicpal block box

Yes, I've added [the ancestor] to what you wrote to be sure of no
ambiguity.

You're right that this appears to contradict 9.2.1, although I suppose
that said that all block boxes were containing blocks for their
descendents, not that all containing blocks were block boxes. It should
have said "in-flow descendents" or something like that.

Note that the only way a containing block can ever be inline is if it is
position:relative.

Any help appreciated in clearing this up .. .I'm sure I'm missing
something

Inline boxes as containing blocks is a bit of a strange idea, and I
don't think any of the browsers I tried get it competely right (Opera,
Konqueror and Firefox) Try this example:

http://www.tidraso.co.uk/misc/inline-cb.html

The consequence of 10.1 as written (and acknowledged) is that you can
get a negative width for the containing block. I can't see how that
could ever be useful.

[Gus Richter]

Ben C wrote:

>
http://www.tidraso.co.uk/misc/inline-cb.html

You cannot have a Block (div) inside an Inline (span).

<http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.tidraso.co.uk %2Fmisc%2Finline-cb.html>

--
Gus

[Ben C]

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

Ben C wrote:

>>
http://www.tidraso.co.uk/misc/inline-cb.html

You cannot have a Block (div) inside an Inline (span).

Yes of course, but you can just make it another span and display:block--
the point is to illustrate how relatively positioned inline boxes form
containing blocks for positioned descendents.

In fact you don't even need to make it display:block since it's
position:absolute anyway.

I shall go and update the page now.

[forgroupsonly]

Hello,

So in the case the ancestor is inline, the containing block is
determined by the boxes it [the ancestor] generates, and not directly
from a prinicpal block box

= = = Citates
9.2.1
Block-level elements ... generate a principal block box

10.1 Definition of "containing block"
4.1. In the case that the ancestor is inline-level ...
4.2. Otherwise, the containing block is formed by the padding edge [p.
100] of
the ancestor.
= = = =

So in the case the ancestor is inline, the containing block is
determined by the boxes it [the ancestor] generates. Principal blcok
box is not applicable in this context (not generated by inline-level
elements). While for block-level elements (4.2) I guess principal block
box assumed.

>Inline boxes as containing blocks is a bit of a strange idea
... you can get a negative width for the containing block.

Yes, negative width is confusing. But even in this case it can be
usefull. In example below 'right' abolutely positioned div sticked to
'left' one.

= = = = =
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head>
<title>Inline containing blocks</title>
<style type="text/css">
.left {
display:inline;
}

.glue {
display:inline;
position:relative;
}

.right {
position:absolute;
left: 0px;
top: 0px;
width: 40px;
height: 40px;
border: 1px dashed gray;
}
</style>
</head>
<body>
<div class="left">
left left left left left left left left left left left
left left left left left left left left left left left
left left left left left left left left left left left
</div>
<div class="glue">
<div class="right">right</div>
</div>
</body>
</html>
= = = = =
But I myself confused by the 9.2.1. words:
Block-level elements (...) generate a principal block box that contains
either only block boxes or
only inline boxes.

What is about a situation when element contains both: block boxes and
inline boxes?
Regards,
- Alex

[Ben C]

On 2007-01-26, fo***********@gmail.com <fo***********@gmail.comwrote:

Hello,

>So in the case the ancestor is inline, the containing block is
determined by the boxes it [the ancestor] generates, and not directly
from a prinicpal block box

= = = Citates
9.2.1
Block-level elements ... generate a principal block box

10.1 Definition of "containing block"
4.1. In the case that the ancestor is inline-level ...
4.2. Otherwise, the containing block is formed by the padding edge [p.
100] of
the ancestor.
= = = =

So in the case the ancestor is inline, the containing block is
determined by the boxes it [the ancestor] generates. Principal blcok
box is not applicable in this context (not generated by inline-level
elements). While for block-level elements (4.2) I guess principal block
box assumed.

Yes.

>>Inline boxes as containing blocks is a bit of a strange idea
... you can get a negative width for the containing block.

Yes, negative width is confusing. But even in this case it can be
usefull. In example below 'right' abolutely positioned div sticked to
'left' one.

There's no negative width there though, you've set the width of .right
to 40px.

The fact that the top left of the containing block for .right is given
by the top left of the first inline box of .glue is useful. It's
anchoring the bottom right to the bottom right of the last inline box of
..glue that can result in a negative width, and which no browser I've
found actually does.

[snip]

But I myself confused by the 9.2.1. words:
Block-level elements (...) generate a principal block box that contains
either only block boxes or
only inline boxes.

What is about a situation when element contains both: block boxes and
inline boxes?

Anonymous block boxes are created as necessary to enclose the inline
boxes. See CSS 2.1 9.2.1.1.

[forgroupsonly]

Hi,

The fact that the top left of the containing block for .right is given
by the top left of the first inline box of .glue is useful. It's
anchoring the bottom right to the bottom right of the last inline box of
.glue that can result in a negative width, and which no browser I've
found actually does.

I just wanted to say, that .glue box (if always kept empty), provide
the means to stick .right div to .left. May be in some design this can
be usefull.

Anonymous block boxes are created as necessary to enclose the inline
boxes. See CSS 2.1 9.2.1.1.

I see, thank you.

- Alex.