[css3-box][css3-lists] New box type for inline formatting contexts

CSS21 tells us that floats, abspos boxes, inline blocks etc establish a 
block formatting context.  Unfortunately, they clearly don't when they 
only contain inline-level content; they establish an inline formatting 
context instead.  Since I don't think we're going to rewrite all the 
bits of CSS21 which are intended to apply to floats etc but which are 
actually worded in terms of BFCs, in css3-box I propose to avoid the 
contradiction by introducing an anonymous block-level box into floats 
etc to wrap the inline-level content.  This will make the CSS21 
descriptions correct.

For example, <div style="float:left">Lorem ipsum</div> will generate a 
principal floated block container box which contains a single anonymous 
block-level box which establishes an inline formatting context.

In current CSS21 terminology, that anonymous block-level box is a block 
container box.


Now, it's always bothered me somewhat that a block container box can 
contain either exclusively block-level boxes or exclusively inline-level 
box (and establish an inline formatting context).  It seems like we're 
oversimplifying; I find the dual nature of block container boxes more 
confusing than having different box types with more specific roles.

I'm putting forward the idea of a new type of box: an "inline container 
box".  The anonymous box described above would be an inline container 
instead of a block container.  The in-flow children of block containers 
would be exclusively block-level, and the in-flow descendents of inline 
containers would be exclusively inline-level.  Inline containers are 
necessarily anonymous block-level boxes, and they play the same game as 
the anonymous block containers described in CSS21 9.2.1.1: depending on 
the DIV's contents, anonymous block containers and anonymous inline 
containers are spawned in order to ensure that in-flow block-level and 
inline-level boxes are not bundled together in the same container. 
Whereas currently in CSS21 all such containers are called block 
containers, now they are either block containers or inline containers 
depending on their contents.

In the case of <p>Lorem ipsum</p> where the paragraph does not establish 
a new formatting context according to CSS21, it generates a principal 
block-level block container box (ie a block box) in CSS21. With the 
introduction of inline container boxes, the principal box would contain 
a block-level inline container box which itself contains the line boxes. 
  There would be no visual difference in the rendering, and whilst the 
containing block of an inline-level descendent of the paragraph would be 
established by the anonymous inline container rather than by the 
paragraph's principal block box, the size and location of that rectangle 
remains the same.

Clearly, this model results in a lot of new boxes in the box tree: every 
block container box which contained inline-level content would now have 
an inline container box inserted between the block container and the 
content.  This extra box is going to have to start being introduced for 
BFC-establishing boxes anyway (as described above), but now we're 
talking about introducing it for general block containers.  This may be 
hard to sell, and I would welcome implementer feedback on the 
consequences of it.  But I think the model offers some advantages, as 
indicated below.


I think we can go some way towards solving the problem with list markers 
in the presence of floats, which is that the markers typically overlap 
the margin area of floats.  There are two steps to making this work.

Step 1:

<p>Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet.
    <span style="float:left; height:100px">float</span>
    Lorem ipsum dolor sit amet.</p>

<p>Abc defg hijk lm nopqr stuv wxyz. Abc defg hijk lm
    nopqr stuv wxyz.</p>

Within the current CSS21 model, the above example is formatted as follows.

,===========DIV===========.
| Lorem ipsum dolor sit   |
| amet. Lorem ipsum dolor |
|,-----. sit amet. Lorem  |
||float| ipsum dolor sit  |
||     | amet.            |
`|     |=================='
  |     |
,|     |====DIV===========.
||     | Abc defg hijk lm |
||     | nopqr stuv wxyz. |
|`-----'                  |
| Abc defg hijk lm nopqr  |
| stuv wxyz.              |
`========================='

With the introduction of inline container boxes, the formatting could be 
as follows. (The block containers of the current CSS model are labelled 
with the element names.)

,===========DIV===========.
|,-----------------------.|
||Lorem ipsum dolor sit  ||
||amet. Lorem ipsum dolor||
|`-----------------------'|
|,-----.,----------------.|
||float||sit amet. Lorem ||
||     ||ipsum dolor sit ||
||     ||amet.           ||
||     |`----------------'|
`|     |=================='
  |     |
,|     |====DIV===========.
||     |,----------------.|
||     ||Abc defg hijk lm||
||     ||nopqr stuv wxyz.||
|`-----'`----------------'|
|,-----------------------.|
||Abc defg hijk lm nopqr ||
||stuv wxyz.             ||
|`-----------------------'|
`========================='

The inline container boxes take over the responsibility for line box 
wrapping from the block containers.  They are split into pieces in any 
situation where a float causes a discontinuity in line box width in the 
existing model.

Step 2:

List marker positioning for list-style-position:outside keys off of the 
inline container box that contains the first line box, instead of keying 
off of the list-item's principal block box.

,===========DIV===========.
|,-----------P-----------.|
||See the following list ||
|`-----------------------'|
|,----------UL-----------.|
||   ,------LI----------.||
||   |,----------------.|||
|| * ||first item that ||||
||   |`----------------'|||
|,-----.   ,-----------.|||
||float|   |spans lines||||
||     |   `-----------'|||
||     |----------------'||
||     |----LI----------.||
||     |   ,-----------.|||
||     | * |second item||||
||     |   `-----------'|||
||     |----------------'||
||     |-----------------'|
`|     |=================='
  |     |
,|     |=====P============.
||     |,----------------.|
||     ||New paragraph   ||
||     |`----------------'|
`|     |=================='
  |     |

We could determine the width of the inline container such that the left 
border edge of the inline container is sufficiently far away from the 
float's right margin edge to allow space to place the marker box without 
it overlapping the float's margin area.  (We would probably describe the 
marker as being out of the normal flow and behaving like abspos in most 
situations but being able to influence layout in this special way.)

In contrast, in the current CSS21 model, that marker for the second list 
item would overlap the float and the line box would begin at the float's 
right margin edge and hence is not indented with respect to the 
following paragraph's line box.


Perhaps in future it will be possible to target the inline container 
boxes with selectors, to give stronger control.  This could help with 
things like blockquotes which have horizontal margin:

,===========DIV===========.
|,-----------P-----------.|
||,---------------------.||
|||The boxes fell silent|||
||`---------------------'||
|,=====.,---------------.||
||float||and it was said|||
||     |`---------------'||
||     |-----------------'|
||     |-BLOCKQUOTE---.   |
||     |   ,---------.|   |
||     |   |Oh, to be||   |
|`==:=='   `---------'|   |
|   |,---------------.|   |
|   ||indented nicely||   |
|   |`---------------'|   |
|   `-----------------'   |
`========================='

That first inline container box of the blockquote could be targeted and 
indented so that its line boxes don't abut the right margin edge of the 
float.

(Unfortunately there's no useful way of automating that indentation, 
though.  It would be necessary to target the box manually.)


Anyhow, the two applications above are merely suggestions of the way in 
which the introduction of inline container boxes could be useful.  I 
suspect such boxes might assist with other issues in future, too.


Thoughts?

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Sunday, 14 October 2012 22:34:29 UTC