Re: [css3-multicol] Column Model Underdefined

Håkon Wium Lie wrote:
> fantasai wrote, on 12 Dec 2007:
> 
>  > The section
>  >    http://www.w3.org/TR/2007/WD-css3-multicol-20070606/#the-multi-column
>  > is somewhat under-defined. It doesn't precisely describe how the model
>  > behaves with page breaks and spanning elements.
>  > 
>  > Here's some proposed text. It may or may not say what you want it to
>  > say, but we can use it as a starting point. It is intended to replace
>  > paragraphs 1, 2, 3, and 6 in section 3, before Example VIII.
> 
> Thanks, this was helpful. I've used much of it, editing it in places. 
> 
> The new draft is available from:
> 
>   http://dev.w3.org/csswg/css3-multicol

Looks pretty good. A few comments...

I wrote:
   | If the multi-column element is paginated, then the height of each row
   | is constrained by the length of the page ...

You got this part. But

   | such that a column box never splits across pages: the column boxes are
   | instead shortened to fit and the rest of the content flowed into a new
   | row of column boxes on the next page.

This part is missing, and it's important, especially the "a column box
never splits across pages" part.


The following two paragraphs are related, so should be placed one right
after the other:

   # It is not possible to set properties/values on column boxes. For
   # example, the background of a certain column box cannot be set and
   # a column box has no concept of padding, margin or borders.
...
   # Future specifications may add additional functionality. For example,
   # columns of different widths and different backgrounds may be supported.

I'd shift the earlier paragraph down to right above the note.


   # Column boxes act as the containing block for their content. However,
   # percentage values are calculated relative to the containing block
   # height are calculated based on the multi-column element's height,
   # not the column box's height.
   #
   # A multi-column element establishes a new block formatting context,
   # as per CSS 2.1 section 9.4.1.
...
   # Column boxes may serve as containing blocks for content that appear
   # inside them. That is, column boxes behave lik block-level, table cell,
   # and inline-block boxes as per CSS 2.1, section 10.1, item 2 [CSS21].
   # However, column boxes do not establish containing blocks for elements
   # with ‘position: fixed’ or ‘position: absolute’.

These three paragraphs are closely related. The first sentence of the
third paragraph is a loosely-worded version of the first sentence in the
first paragraph. I would merge these as follows:

   | Column boxes act as the containing block for their content. That is,
   | column boxes behave like block-level, table cell, and inline-block
   | boxes as per CSS 2.1, section 10.1, item 2 [CSS21]. However, column
   | boxes do not establish containing blocks for elements with
   | ‘position: fixed’ or ‘position: absolute’. Percentage values that are
   | calculated relative to the containing block height are calculated
   | based on the multicol element's height, not the column box's height.

To coordinate with the examples, I'd place this paragraph after example
VIII and shift example X up before the paragraph about floats.

And because we changed the rules for BFCs to not collapse with their
children, I'd shift the BFC sentence down and put it with the margin
collapsing clause, thus:

   | A multi-column element establishes a new block formatting context,
   | as per CSS 2.1 section 9.4.1. However, the top margin of the first
   | element and the bottom margin of the last element collapse with
   | the margins of the multi-column element as per the normal rules for
   | collapsing.

Thanks for the great work on this draft, Håkon! I think we might be
able to get this in Last Call towards the end of this year. :)

~fantasai

Received on Tuesday, 24 February 2009 08:18:09 UTC