- From: Håkon Wium Lie <howcome@opera.com>
- Date: Tue, 24 Feb 2009 12:42:45 +0100
- 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 UTC