- 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