Re: [CSS21] Distinguishing block boxes, block containers, and block-level elements

fantasai wrote:
> Wherein fantasai corrects a couple more glitches.
> 
> CSS2.1 Issue 120
>     http://wiki.csswg.org/spec/css2.1#issue-120
> 
> *** TAKE IV ***
> 
> The approach taken is to define existing terms more precisely, define a
> couple of new terms, and use all of these terms more accurately throughout
> the specification. Errors that were corrected include use of "block-level"
> when "block box" was meant and vice versa, use of "inline-level" when
> "inline box" was meant and vice versa, lists that mistakenly left out
> table-cells or table-captions, and lists that mistakenly left out inline
> blocks or inline tables.
> co
> These changes also make CSS easier to extend with new layout models,
> as they make the text less dependent on specific 'display' values by
> consistently using terms that capture key distinctions in how boxes
> behave.


These terms are great to have resolved. I would like to see that the 
spec in consistent in the use of the terms and how such boxes (either 
block or inline) behave in pages with both 'block formatting context' 
and 'inline formating context' [1].


It wound be good if the spec could say that 'block-level' elements and 
'block boxes' operate in a block formating context and 'inline-level' 
elements or 'inline boxes' operate in a inline formatting context. 
This is partly mentioned below with the suggested changes in 9.4 for 
normal flow.



> Proposed changes follow:
> 
> Section 8.3.1 Collapsing margins
> 
>     # Two or more adjoining vertical margins of block boxes in the normal
>     # flow collapse.
> 
>     s/block boxes/block-level box/


Side note: I presume "s/block boxes/block-level box/" means 
substituting the term 'block boxes' with 'block-level box'.


[snip]
> Section 9.2.1 Block-level elements and block boxes
> 
>     Replace
> 
>     # Several values of the
> 
>    with
> 
>     | The following values of the
> 
>     Replace
> 
>     # Block-level elements (...) 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.
> 
>     with
> 
>     | <dfn>Block-level boxes</dfn> are boxes that participate in a
>     | _block formatting context_. Each block-level element generates a
>     | principal block-level box that contains descendant boxes and
>     | generated content and is also the box involved in any positioning
>     | scheme.
> 
>     and append contents of the next paragraph:
> 
>     # Some block-level elements generate additional boxes outside of the
>     # principal box: 'list-item' elements. These additional boxes are
>     # placed with respect to the principal box.
> 
>     Start a new paragraph.
> 
>     | Except for table boxes, which are described in a later chapter,
>     | and replaced elements, a block-level box is also a block container
>     | box. A <dfn>block container box</dfn> either contains only
>     | block-level boxes or establishes an inline formatting context and
>     | thus contains only inline-level boxes. Not all block container
>     | boxes are block-level elements: non-replaced inline blocks and
>     | non-replaced table cells are block containers but not block-level
>     | boxes. Block-level boxes that are also block containers are called
>     | <dfn>block boxes</dfn>.
>     |
>     | The three terms 'block-level box', 'block container box', and
>     | 'block box' are sometimes abbreviated as 'block' where unambiguous.
> 
>     The effects of these changes are to define three terms:
>       block-level box or element
>       block container box
>       block box ( = block-level block container box )


Does this mean the term 'containing block' is not to be used anymore 
and is to be replaced with the term 'block container box'? Example.

       | Absolutyly positioned boxes are offset to there 'block 
container box'

Also above in the part "Start a new paragraph." there is this.

 >     | Not all block container
 >     | boxes are block-level elements: non-replaced inline blocks and
 >     | non-replaced table cells are block containers but not block-level
 >     | boxes.

We have two similar terms which are 'block container boxes' and 'block 
containers'.


> Section 9.2.1.1 Anonymous block boxes
> 
>     # In other words: if a block box (such as that generated for the DIV
>     # above) has another block box or run-in box inside it (such as the P
>     # above), then we force it to have only block boxes and run-in boxes
>     # inside it.
> 
>     s/if a block box/if a block container box/
>     s/another block box or run-in box/a block-level box/
>     s/only block boxes and run-in boxes/only block-level boxes/


I not sure why we must have 'block container box' since the function 
of it be something that is a container is a references to it being a 
container for a descendant element.



>     # When an inline box contains a block box, the inline box (and its
>     # inline ancestors within the same line box) are broken around the
>     # block. The line boxes before the break and after the break are
>     # enclosed in anonymous boxes, and the block box becomes a sibling
>     # of those anonymous boxes. When such an inline box is affected by
>     # relative positioning, the relative positioning also affects the
>     # block box.
> 
>     s/around the block/around the block-level box/
>     s/block/block-level/g
>     s/enclosed in anonymous boxes/enclosed in anonymous block boxes/
> 
> Section 9.2.2 Inline-level elements and inline boxes
> 
>     # Several values of the 'display' property make an element inline:
> 
>     s/inline/inline-level/
>     s/Several values/The following values/
> 
>     # 'inline', 'inline-table', 'inline-block' and 'run-in' (part of
>     # the time; see run-in boxes). Inline-level elements generate
>     # inline boxes.
> 
>     Replace "inline boxes" with "<dfn>inline-level boxes</dfn>, which
>     are boxes that participate in an inline formatting context".
> 
>     Append a new paragraph:
> 
>     | An <dfn>inline box</dfn> is one that is both inline-level and whose
>     | contents participate in its containing inline formatting
>     | context. A non-replaced element with a 'display' value of 'inline'
>     | generates an inline box. An element with a 'display' value of 
> 'run-in'
>     | can also generate an inline box; see _run-in boxes_.
>     | Inline-level boxes that are not inline boxes (such as
>     | replaced inline-level elements, inline-block elements, and 
> inline-table
>     | elements) are called <dfn>atomic inline-level boxes</dfn> because 
> they
>     | participate in their inline formatting context as a single opaque 
> box.


Do we need the term 'containing inline formatting context'?


[snip]
> Section 9.4 Normal flow
> 
>     # Block boxes participate in a block formatting context. Inline boxes
>     # participate in an inline formatting context.
> 
>     s/Block boxes/Block-level boxes/
>     s/Inline boxes/Inline-level boxes/
> 
> Section 9.4.1 Block formatting contexts
> 
>     Replace
> 
>     # Floats, absolutely positioned elements, inline-blocks, table-cells,
>     # table-captions, and elements with 'overflow' other than 'visible'
> 
>     with
> 
>     | Floats, absolutely positioned elements, block containers (such as
>     | inline-blocks, table-cells, and table-captions) that are not block
>     | boxes, and block boxes with 'overflow' other than 'visible'
> 
>     # Vertical margins between adjacent block boxes in a block formatting
>     # context collapse.
> 
>     s/block boxes/block-level boxes/


I question the use of the term 'block containers' since inline-blocks, 
table-cells, and table-captions can be empty boxes or boxes with 
inline boxes (some which may overflow it's parent).


> 
[snip]
> Section 9.5 Floats
> 
>     # In other words, if inline boxes are placed on the line ... and
>     # then the inline boxes already on the line
> 
>     s/inline/inline-level/g
> 
>     # The outer top of a floating box may not be higher than the outer
>     # top of any block or floated box
> 
>     s/block/block-level/


Why not 'block container'? The block that is referred to above is a 
parent element. If it is a sibling 'block-level box' then the outer 
top of a floating box may not be higher than the outer bottom edge of 
any sibling block-level box that occurs earlier in the flow.

   <p>block-level box</p>

   <div style="float: left">float</div>

The floated div outer top edge (possibly margin box) will sit level 
with outer bottom edge of the p.


[snip]
> Section 10.2 Content width: the 'width' property
> 
>     # This property specifies the content width of boxes generated by
>     # block-level and replaced elements.
> 
>     s/generated by block-level and replaced elements//


What is the substitution here?


>     # This property does not apply to non-replaced inline-level elements.
> 
>     s/inline-level/inline/
> 
>     # For absolutely positioned elements whose containing block
>     # is based on a block-level element
> 
>     s/block-level/block container/


Here we now have the terms 'containing block' and 'block container' 
mentioned together.



[snip]
> 
> ~fantasai
> 
> 
> 
> 
> 



1. <http://www.w3.org/TR/CSS21/visuren.html#inline-formatting>



-- 
Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo

Received on Saturday, 21 August 2010 09:25:55 UTC