Re: Questions about 'column-span'

On May 21, 2010, at 10:14 AM, Bert Bos wrote:

> 
> Usually there is no such element, though. A typical mark-up would be
> 
>    <section>
>      <h>The title</h>
>      <p>...
>      <p>...
>    </section>
> 
> with
> 
>    section {columns: 2}
>    h {column-span: all}
> 

Yeah, the HTML5 example occurred to me too.  It's a good example of markup that you'd like to be able to style this way.

>> 
>> (2) How far into the descendants of the column can you go and still
>> honor a column-span?  For example, can a block inside an inline-block
>> that is in a multi-column layout really "break out" of the
>> inline-block and span the whole set of columns?  What about
>> descendants of an overflow:hidden element inside a multi-column
>> element?  I'm not sure that case even makes sense.
>> 
>> My own proposal for resolving this would be thatHow would you get the 
> same rendering without 'column-span'? column-span can only
>> apply to objects within the same block formatting context as the
>> multicol block.  That prevents objects inside overflow:hidden blocks
>> or inline-blocks from being considered.
> 
> That makes sense. The columns that 'column-span' refers to are those of 
> the root of the current block formatting context. (If that root is not 
> a multi-column element, then there are no columns to span 
> and 'column-span' has no effect.)
> 
> In the example below, all H elements span across two columns, but the P 
> inside the floating DIV does not.
> 
>    <SECTION STYLE="columns: 2">
>      <H STYLE="column-span: all">Top-level heading</H>
> 
>      <SECTION>
>        <H STYLE="column-span: all">Second-level heading</H>
>        ...
> 
>        <DIV STYLE="float: left">
>          <P STYLE="column-span: all">Floating para.
>        </DIV>
>      </SECTION>
> 
>      ...
>    </SECTION>
> 

Yeah I think that will be a nice way of clarifying whether the column-span takes effect or not.

>> 
>> (3) Can the column-span element be an inline?  I'm inclined to say
>> that it has to be a block-level element.  It seems weird to me to
>> break an inline out of flow like that (that could possibly span
>> multiple lines).  You'd have to at the very least make an anonymous
>> block to wrap the inline anyway.
> 
> It obviously has to be block-level, but that leaves two possibilities:
> 
>  - 'column-span <> 1' *makes* the element into a block, or
>  - 'column-span' only *applies* to block-level elements.
> 
> The second seems by far the easiest to understand and is sufficient, I 
> think.
> 

I prefer the second also.

> 
>> 
>> (4) What happens to the margins of a column-span element?
>> 	(a) Do its margins disappear?
>> 	(b) Do they stick around but not collapse with the columns before or
>> after? (c) Does a column-span element collapse its margins with the
>> top of the multicol block? With the bottom? (d) What happens to two
>> contiguous column-span elements with no column content between them?
>> Do their margins collapse with one another?
> 
> I'd say:
> 
> (a) No, margins don't disappear.
> 
> (b) Is the question if the H2 and the P in this fragment collapse their 
> margins?
> 
>    <DIV STYLE="columns: 2">
>      <H2 STYLE="column-span: all; margin-bottom: 1em">HHHH...</H2>
>      <P STYLE="margin-top: 1em">PPPPPPPPP...
>    </DIV>
> 
> In other words, does it look like the left or the right image?
> 
>    HHHHHHHHHHHHHHHH           HHHHHHHHHHHHHHHH
>    HHHHHHHHHHHH               HHHHHHHHHHHH
> 
>    PPPPPPP  PPPPPPP                    PPPPPPP
>    PPPPPPP  PPPPPPP           PPPPPPP  PPPPPPP
>    PPPPPPP  PPPPPPP           PPPPPPP  PPPPPPP
>    PPPPPPP  PPPPPPP           PPPPPPP  PPPPPPP
> 
> I think I prefer the left image, i.e., the margins do collapse between 
> spanning elements and their non-spanning siblings.
> 

I prefer the left image too, although to achieve it, I think it might be sufficient to just say that margins that collapse with the top of the first column box just resolve to 0 (similar to what happens if you're at the top of the other columns with unforced breaks.  It seems atypical that the first element in the column would have a larger margin than the spanning element.

> (c) No, the spec says that a multi-column element is the root of a block 
> formatting context, so its margins do not collapse with its children's 
> margins. (In a way that's a pity, but it's what the spec says...)
> 

That's not what WebKit does.  We let the margin on an element in the first column collapse through the multi-column block, but we could change that if we have a solution that will auto-drop the margin off the first <p> in a column.

This seems like an issue we need to correct somehow.  I mean if you have a multi-column block with a sequence of paragraphs, we can't have the first paragraph starting 1em into the column.  That would just look silly.  Authors shouldn't have to worry about resetting the top margin on the first element in a column.  They don't have to worry about it on the first page of a printed document or at the top of the document in continuous media...

The simplest way to resolve this issue may be to just apply the rule I suggested above, i.e., that you think of the top of the first column kind of like the top of a page, and let the margins resolve to 0.  This seems reasonable to me, since starting a column is somewhat similar to an unforced column/page break.

>> (5) Does a column-span element establish a new block formatting
>> context?  For example, a column-span element could contain floats
>> that protrude from its space, unless we say that it grows to
>> encompass those floats.  If a column-span element does have floats
>> that protrude, do the following columns attempt to avoid the float? 
>> Again the question of contiguous column-span elements comes up.... if
>> the first element has an overhanging float does the content of the
>> second column-span element avoid it?
> 
> Good question. On the one hand we want the margins of the DIV and the P 
> in the following fragment to collapse:
> 
>    <SECTION STYLE="columns: 2">
>      ...
>      <DIV STYLE="column-span: all; margin-top: 1em">
>        <P STYLE="margin-top: 1em">...
>      </DIV>
>      ...
>    </SECTION>
> 
> On the other hand, it's probably not nice if a float that protrudes 
> partly out of a spanning element is partly clipped:
> 
>    xxxxxxxx  xxxxxxxx  xxxxxxxx
>    xxxxxxxx  xxxxxxxx  xxxxxxxx
> 
>    ############# XXXXXXXXXXXXXX
>    ############# XXXXXXXXXXXXXX
>    ############# XXXXXX
>    #############
>    ########  xxxxxxxx  xxxxxxxx
>    ########  xxxxxxxx  xxxxxxxx
>    xxxxxxxx  xxxxxxxx  xxxxxxxx
>    xxxxxxxx  xxxxxxxx  xxxxxxxx
> 
> But the latter can be avoided by the designer with 'clear-after: left' 
> (or whatever mechanism we settle on that has the same effect).
> 
> So I prefer to *not* make the spanning element into the root of a 
> separate flow.

I think as a first cut we could just be silent on this issue and UAs could just let the float stick out and overlap the columns.

> 
>> 
>> (6) What happens with nested column-span elements when the outer
>> column-span element establishes a 2nd nested set of columns?  Do the
>> margins of the outer column-span element and the inner column-span
>> element collapse together if they are contiguous?
> 
> That outer spanning element is itself a multi-column element and thus it 
> is the root of a block formatting context. That means it does not 
> collapse margins with its children.

I see.  Note that with the anonymous block split model I outlined in my other messages we'd be able to achieve this collapse without violating that rule, i.e., the wrapped anonymous multicol blocks would become the BFCs, and the original multicol block would no longer establish a BFC.  This would allow floats to protrude out of a column-span at the bottom of a multi-col block as well (in addition to allowing collapse of margins across nested column-spans).

> 
>> 
>> (7) What background renders behind a column-span element when its
>> transparent?
> 
> None? (I don't understand the question: transparent means no background, 
> doesn't it?)
> 

I was mainly asking if the ancestor blocks with no span render their backgrounds behind the spanning element.  I am inclined to think that - like blocks inside inlines - you don't have any actual inline box behind the block, so the answer is nothing.

>> 
>> (8) If the column-span element has horizontal or vertical margins,
>> what are the hit testing rules when you're in those margins?  Are you
>> inside the parent element of the column-span (which itself may just
>> be in columns) or are you in the multicol block?
> 
> The CSS spec has so far not defined to which element a margin belongs. 
> So this is undefined even without columns.
> 

Yeah, I noticed that CSS2.1 doesn't define this for blocks inside inlines (CSS3 maybe should), so I think you're right that it could just be unspecified in the multicol spec.

Thanks for the answers!  It sounds like we have a similar view on how this property would look.

dave
(hyatt@apple.com)

Received on Friday, 21 May 2010 17:42:49 UTC