Review comments on css3-multicol CR 2011-04-12

Hi,

I have some comments on the multicol CR of 12 April 2011.


Issue 1:

Section 2 (The multi-column model) describes column boxes.  They are not 
described as establishing new block formatting contexts; only the 
multicol box does that.  I think this is flawed.  If columns don't form 
BFCs then we have to worry about lots of things including margin 
collapsing between column content and columns and the scope of clearing 
elements.  Note that this section says:

   # Floats that appear inside multi-column layouts are positioned with 
regard to the column
   # box where the float appears.

so either the column establishes a BFC or else a column box has a 
property that has not appeared to date in CSS.


Issue 2:

Related to Issue 1 above, if columns provide scope for floats and yet 
are not BFCs, do they also provide scope for clears?


Issue 3:

Related to Issue 1 above, if columns provide scope for floats are yet 
are not BFCs, are they allowed to "bleed" out of the bottom of short 
columns?


Issue 4:

Section 2 (The multi-column model) says:

   # Column boxes act as the containing block for their content.

Various specs use similar wording, but it's always clumsy.  Obviously 
they only act as the containing block for descendants for whom they are 
the containing block.  We could say something like "Column boxes 
participate in the tree of containing blocks", but there's currently no 
such concept described anywhere (despite existing conceptually), so 
instead I suggest we just say:

   | Column boxes are block container boxes.

Then the fact that they form part of the tree of containing blocks falls 
out naturally and doesn't need explicitly stating.


Issue 5:

The 'column-width' and 'column-count' (and hence 'columns') properties 
are given as applying to "non-replaced block-level elements (except 
table elements), table cells, and inline-block elements".

At the very least, "table elements" should be "internal table elements" 
since I guess there's no reason why a table caption shouldn't be a 
multicol element.

Better still, this sentence should be replaced with "block containers", 
as per many other properties in CSS21 that were updated prior to PR.


Issue 6:

3.1 ('column-width') says:

   # To set an exact column width, all length values (in horizontal text 
these are: 'width',
   # 'column-width', 'column-gap', and 'column-rule-width') must be 
specified.

This sentence, which appears in a note, contradicts the following 
sentence from the note in 3.4 (Pseudo-algorithm):

   # However, both ‘column-width’ and ‘column-count’ are honored when 
the width of the
   # element has not been determined.

That the earlier sentence is false is also evident from the 
pseudo-algorithm.

Moreover, another problem with the earlier sentence is that it's 
possible to "get lucky" and have the specified non-auto column width 
turn out to be the used width depending on the state of the other 
properties, so the sentence isn't quite true.

Hence the earlier sentence needs revising.


Issue 7:

3.5 (Stacking context) says:

   # All column boxes in a multi-column element are in the same stacking 
context and the
   # drawing order of their contents is as specified in CSS 2.1.

This isn't quite good enough since the outward behaviour of a column box 
isn't explicitly defined (albeit that the description in Section 2 is 
intended to be a sufficient summary of their behaviour).  The painting 
model specified in CSS 2.1 only describes the behaviour of box types 
known to CSS 2.1; new box types need to "fitted in" to the painting 
model explicitly.  Happily CSS 2.1 makes this as easy as possible for 
typical new box types: they merely need to be defined as 
"non-inline-level" (see CSS 2.1, 9.1.1, painting layer 3).  This 
information /does/ need to be provided in specs that define new boxes, 
though, even though it might be "obvious".

Also, it seems to be the intention that column boxes do not necessarily 
establish new stacking contexts; this needs to be stated explicitly.

(It's nice to see a section on stacking contexts, btw!  It's overlooked 
in the drafts of some of the other specs.)


Issue 8:

4 (Column gaps and rules) says:

   # Column rules are painted just above the background of the multicol 
element. This allows
   # child elements with ‘z-index’ values to be on top of column rules.

s/allows child elements with ‘z-index’ values to be/ensures child 
elements are always painted/
since every element has z-index (albeit sometimes auto) so it's not 
necessary to mention it.  My impression is that the intention of the 
sentence is to point out that there's no way of putting a child element 
below the column rule.

However, my proposal does assumes that the multicol element establishes 
a new stacking context.  This seems reasonable, and it should be stated 
if that's indeed the case.  The quoted sentence remains true if 
multicols don't establish new stacking contexts, but the result is 
rather unexpected and the quoted sentence should be changed to make the 
possible renderings more explicit in that case.


Issue 9:

Section 5 (Column breaks) fails to describe how content is split from 
one column to the next, and does not make reference to such a 
description in any other spec.  It does state:

   # The problem of breaking content into columns is similar to breaking 
content into pages.

This isn't really good enough, although I accept that there isn't yet a 
definitive place which describes breaking behaviour but that it's 
generally preferred that specs which rely on such behaviour do not try 
to define it themselves.  IMO this section certainly needs to reference 
/something/; currently the most suitable candidate is 13.3.3 (Allowed 
page breaks) of CSS21.[1]  Such a reference might be implied from the 
wording in Section 5, but it should be explicitly given.


Issue 10:

6.1 ('column-span') states that the 'column-span' property applies to 
"block-level elements, except floating and absolutely positioned 
elements".  This should be replaced with the equivalent and more 
succinct "in-flow block-level elements".


Issue 11:

6.1 ('column-span') implies that any block-level descendent of a column 
box can be a spanner.  Such an unrestricted model doesn't make much 
sense to me.  Surely only elements which participate in the block 
formatting context of one of the columns should be allowed to span. What 
are the use cases for allowing spanning from within a nested BFC such as 
an inline-block, an overflow-scroll element, a float or an abspos element?


Issue 12:

6.1 ('column-span') and 7.1 ('column-fill') define the computed value of 
the respective properties to be "as specified".  This is the vague 
terminology of CSS 2.1 and I think that the level 3 specs should avoid 
it.  Does it mean "the specified value" as per the properties defined in 
5.1 for example, or does it mean "as described in the prose"?


Issue 13:

6.1 ('column-span'), Example XX contains a typo: "the first sentence in 
the fourth sentence".


Issue 14:

6.1 ('column-span'), Example XXI demonstrates how UAs may choose not to 
make an element spanning if there is "no room" to do so.  However, the 
example shows the "obvious" case; it would be more enlightening if it 
showed the less obvious case in which the columns do not need to 
overflow when the heading (possibly initiated in the first or second 
column) is non-spanning but where the columns would overflow were the 
heading allowed to span.


Issue 15:

What is the relationship between the 'column-fill' property (7.1) and 
the break properties (5) for example as demonstrated in 8.2 Example 
XXIV?  Presumably balance is disrupted in the presence of an explicit 
break, but how exactly?


Issue 16:

8.2 (Pagination and overflow outside multicol elements) says:

   # Content and column rules that extend outside column boxes at the 
edges of the multi-
   # column element are clipped according to the ‘overflow’ property.
   #
   # A multicol element can have more columns than it has room for due to:
   #
   #   *  a declaration that constrains the column height (e.g., using 
‘height’ or ‘max-height’).
   #      In this case, additional column boxes are created in the 
inline direction
   #   *  the size of the page. In this case, additional column boxes 
are moved to the next
   #      page(s).
   #   *  explicit column breaks. In this case, additional column boxes 
are created in the inline
   #      direction for continuous media, and additional column boxes 
are moved to the next
   #      page(s) for paged media.

In the second case, presumably the multicol element itself is split 
across pages, so it's not clear to me that this case is relevant to the 
situation of a multicol element having "more columns than it has room for".


Issue 17:

   # Columns that appear outside the multicol element in continuous 
media are called
   # overflow columns.

Is it true that a column is either entirely outside of the multicol 
element or entirely inside it?  (Quite possibly this falls out of the 
pseudo-algorithm, but I haven't checked in detail.)



[1] http://www.w3.org/TR/CSS2/page.html#allowed-page-breaks


Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Thursday, 1 December 2011 22:27:30 UTC