W3C home > Mailing lists > Public > www-style@w3.org > May 2010

Re: Suggested text for 'column-span'

From: David Hyatt <hyatt@apple.com>
Date: Thu, 20 May 2010 14:16:40 -0500
Cc: www-style@w3.org
Message-id: <6D14B0C2-43EF-445B-9C5E-9922006CA1FA@apple.com>
To: "L. David Baron" <dbaron@dbaron.org>
On May 20, 2010, at 1:57 PM, L. David Baron wrote:

> On Thursday 2010-05-20 13:41 -0500, David Hyatt wrote:
>> When a multi-column block contains a spanning element, all of the
>> containing block ancestors are broken around the spanning element.
>> The column boxes before and after the break are enclosed in
>> anonymous boxes, and the spanning element becomes a sibling of
>> those anonymous boxes.
> I'm not sure I follow exactly what you're suggesting in this part.
> What are "containing block ancestors"?  And where exactly are the
> anonymous boxes?  Are they in the first and third parts of the split
> (the multicolumn parts), or the second part of the split (the
> spanning part), or both?

The containing block ancestors are just the parent block boxes.  It occurred to me after I sent the message that since I made the normal flow requirement I could just say parent boxes.

Just comparing with block-inside-inline, a block with inline children contains a sequence of root line boxes, each of which has a tree of inline line boxes inside it.  If you drop a block box into one of those lines, you split all of the ancestor inline boxes all the way back up to the block.

<div><span>Hello world</span></div>

starts off with one line box:

  [ [span] Hello world [span] ]

Drop a div in between "Hello" and "world", and you end up splitting the inlines (in this case a single span), and creating anonymous block-level boxes to wrap the pre-split and post-split line boxes.

  [Anonymous Block]
    [ [span] Hello [/span] ]
  [Anonymous Block]
    [ [span] world [/span] ]

I am proposing that a column-span element works in a similar fashion.  In this analogy column boxes are like line boxes, block boxes inside column boxes are like inline line boxes, and the column spanning element is like the block that got tossed into the inline.

You'd split the same way, so let's say you start off with:

  [...column 1 contents...]
  [ [div]Hello world[/div] ] <-- column 2

And you throw a column spanning element in between "Hello" and "world", you end up splitting the blocks (in this case a single div), and creating anonymous block-level boxes to wrap the pre-split and post-split boxes in the columns.

[div] (no longer formats its kids as multi-col)
  [Anonymous Block formatting its kids as multi-col]
    [... column 1 contents... ]
    [ [div]Hello[/div] ]
  [div]... spanning element contents... [/div]
  [Anonymous Block formatting its kids as multi-col]
    [ [div]world[/div] ]

> I think I'd want to see horizontal margins on the multicolumn
> element and on elements between the multicolumn element and the
> spanning element continue to work.  (Also side borders on the
> multicolumn element itself.)

Horizontal margins on the multicolumn element would work.  I would not expect horizontal margins on ancestors of the spanning element to inset the spanning element.  If you're suggesting that, I disagree that that should work.  Side borders on the multi-column element itself would work just fine with my proposal.  The multi-column element itself is not being split.

> Making that work, I think, suggests a model where there actually
> aren't any anonymous boxes at all:  all ancestors of the spanning
> element, up to and including the multicolumn element, should get
> split into three parts.  In the first and third parts the
> multicolumn element would lay out in multiple columns; in the middle
> part it would lay out as one column.  (Should those parts get
> omitted if there would otherwise be nothing in them?)

I think anonymous boxes are convenient to wrap the three-part split.  That's essentially why we do it for inlines.  It tends to be simpler in the block-inside-inline case implementation-wise to either have all block kids or all inline kids and not to have to maintain a mixed sequence of both.  I think the same would hold true for columns... that it would be easier to say you only have column boxes or block boxes when dealing with a multi-column block's children.

Received on Thursday, 20 May 2010 19:23:46 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:46 UTC