[CSS21][css3-flexbox][css3-multicol] (Appendix E) Almost everything is block-equivalent! (Was: Re: [CSS21] (Appendix E) Are inline-blocks "block equivalent"?)

On 15/05/2012 00:05, Anton Prowse wrote:
> On 11/05/2012 16:07, Simon Sapin wrote:
>> Appendix E uses this sentence twice:
>> "If the element is a block, list-item, or other block equivalent"
>>
>> What is a "block equivalent"? Do inline-blocks fall in that category?
>>
>> I’m trying to figure out how to make sure that inline-blocks (that may
>> or may not be positioned, with z-index that may or may not be 'auto')
>> get their background and borders painted exactly once...
>
> Yes, this does seem a bit muddled, doesn't it.
>
> As I read it, inline-blocks and inline-tables which establish stacking
> contexts don't get their backgrounds painted at all in the algorithm,
> unless they're covered by "block equivalent" in Step 2.
>
> I think Step 2 should in fact be talking about block containers.
>
> Replace:
>    # Step 2: If the element is a block, list-item, or other block
>    #         equivalent:
> with
>    | Step 2: If the element is a block container or block-level replaced
>    |         element:
>
> Similarly, replace:
>    # Step 4: For all its in-flow, non-positioned, block-level
>    #         descendants in tree order: If the element is a block,
>    #         list-item, or other block equivalent:
> with:
>    | Step 4: For all its in-flow, non-positioned, block-level
>    |         descendants in tree order:
>    |         If the element is a block container or replaced element:

In fact, this issue goes deeper than just CSS21.  Neither css3-flexbox 
nor css3-multicol say anything about painting order in the general case, 
so we must assume that flex containers, flex items, multicol boxes and 
column boxes are all expected to be interpreted as "block equivalent".

So to support that interpretation, following my rationale below, "block 
container" in my suggested replacement text should be generalized even 
further to support containers from future specs.

I propose the following revision.

Replace:
    # Step 2: If the element is a block, list-item, or other block
    #         equivalent:
with
    | Step 2: If the element is a block container (or other
    |         container as defined in future levels of CSS) or
    |         a block-level replaced element:

and similarly for Step 4.

That way, css3-flexbox and css3-multicol can continue to ignore the 
issue of painting order in the general case instead of needing to say 
that for the purposes of painting order, its various containers are 
regarded as being block-equivalent.


Rationale:

css3-multicol claims that multicol boxes establish new block formatting 
contexts (which is odd because the column boxes they contain are not 
laid out like CSS21 blocks), which would imply that they are block 
containers.  Column boxes are specified as being block containers in the 
Editor's Draft, which is a sensible model.  They do not establish a new 
BFC, and they are not inline-level. [One might infer that they are 
block-level since a multicol box establishes a BFC; but again this is a 
questionable model].

I think that, in reality, a multicol box is a "column container" and it 
establishes a new "multi-column formatting context" which happens to 
share a lot of characteristics of a block formatting context.  A column 
box is then a column-level block container box.

The flexbox model is tighter: a flex container establishes a new flex 
formatting context, and a flex item is a flex-level box which 
establishes a new formatting context and which is a container box (by 
virtue of the fact that all boxes which establish a new formatting 
context are container boxes with the possible exception of table boxes - 
which can't be flex items anyhow since it's the /wrapper/ box that's the 
flex item).


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

Received on Thursday, 12 July 2012 07:33:11 UTC