W3C home > Mailing lists > Public > www-style@w3.org > February 2009

Re: [css3-multicol] Column Model Underdefined

From: Håkon Wium Lie <howcome@opera.com>
Date: Tue, 24 Feb 2009 12:42:45 +0100
Message-ID: <18851.56629.525319.620958@opera.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: WWW Style <www-style@w3.org>
Also sprach fantasai:

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

I think this is covered by the statement: 

  If the multi-column element is paginated, then the height of each
  row is constrained by the page, and the content continues in a new
  row of column boxes on the next page.

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

Done.

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

This is good, added.

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

Could you check to see if it make sense what's in the newly updated draft?

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

The first line would be a repetition. I think the text is ok as is.

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

Why wait? Why not send to LC now? The syntax has been stable for years
and we have two (partial) implementations...

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Tuesday, 24 February 2009 11:43:34 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:16 GMT