Re: Questions about 'column-span'

On Thursday 20 May 2010 10:49:11 David Hyatt wrote:
> I was thinking about the column-span property as I rewrite
> multicolumn layout in WebKit, and it seems pretty crazy to me.
>
> http://www.w3.org/TR/2009/CR-css3-multicol-20091217/#column-span
>
> (1) Are there any implementations of this property yet?  My own vote
> would be for cutting it, since the desired effect can be pretty
> easily obtained by just wrapping the contents underneath headings in
> a block and putting multi-column styles on those content blocks.

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}

>
> (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>

>
> (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.

In some case you would have to add a 'display: block' to make 
the 'column-span' work, e.g. in this case:

    IMG {column-span: all; display: block}

But that is not unusual for IMG.

>
> (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.

But only if there are no intervening non-empty elements. It would be 
difficult to collapse with earlier or later elements that happen to be 
adjacent because they are at the top or bottom of a different column:

    <DIV STYLE="columns: 2">
      <H2 STYLE="column-span: all; margin-bottom: 1em">HHHH...</H2>
      <P STYLE="margin-top: 1em">PPPPPPPPP...
      <P STYLE="break-before: always; margin-top: 1em">QQQQQQQQQ...
    </DIV>

    HHHHHHHHHHHHHHHH
    HHHHHHHHHHHH

    PPPPPPP  
    PPPPPPP  QQQQQQQ
    PPPPPPP  QQQQQQQ
    PPPPPPP  QQQQQQQ

(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...)

(d) Yes, two sibling elements with the same 'column-span' value collapse 
their margins. E.g., the positions of the two H2s in the following 
fragment do not depend on Y:

    <DIV STYLE="columns: 1">
      ...
      <H2 STYLE="column-span: Y">Heading 1</H2>
      <H2 STYLE="column-span: Y">Heading 2</H2>
      ...
    </DIV>

>
> (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.

>
> (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.

>
> (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?)

>
> (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.

It's probably most intuitive in general when hit testing is done using 
the border box for elements that have a border and/or a non-transparent 
background, and using the content box for other elements. But this 
would need more investigation. It is not something we can define in the 
multi-column spec.



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Friday, 21 May 2010 15:13:58 UTC