Re: [css3-multicol] Review comments on css3-multicol CR 2011-04-12

Hello Anton,

Thanks for your thorough review of css3-multicol. My comments are
inline. In summary, I agree to some editorial changes in the spec and
solicit more feedback on other topics.

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

I'm not sure that columns should establish BFCs. One reason for not
doing so is intrusions -- I believe we want floats to be able to
intrude from one column to another in the future:

  http://www.w3.org/TR/css3-gcpm/#multi-column-float-intrusion

If we make columns BFCs, we cannot add intrusions this way, can we?

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

The main point that the sentence makes is that column boxes act as
containing blocks. The last part, "for their content" can probably be
dropped, but I don't really see what harm it does. 

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

Hmm. I don't see anything wrong with stating that columns are
containing blocks for their content, and I don't see how your proposed
text improves the spec.

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

Internal table elements are defined to mean:

  "internal table element is one that produces a row, row group,
  column, column group, or cell."

  http://www.w3.org/TR/CSS2/tables.html#tables-intro

So, the definition of an 'internal table element' excludes tables (as
in <table>). When the multicol spec refers to 'table elements', I
believe it means <table> elements with and not the CSS 2.1 definition
of "table elements", which is:

  In this specification, the term /table element/ refers to any element
  involved in the creation of a table.

I'm not sure I like the CSS 2.1 definition as it leaves us without a term for
referring to <table> elements. 

Also, "internal table elements" include table cells, which the
properties specifically applies to.

I agree that the properties should apply to table captions, though.

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

I only see 'overflow' and 'text-align' applying to 'block containers'
in CSS 2.1; 'widows' and 'orphans' apply to 'block container elements'. 

Is this difference intentional? 

And, where is the definition of "block containers"? It doens't appear
in the CSS 2.1 index.

Given all this, perhaps you could come up with a revised proposal?

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

Let's see.

The first quote states that, if you want to set *exact* dimesions, you
need to specify all length values.

The second quote states conditions when two properties are *honored*.

Now, honoring "column-width" is not the same as setting the column
width exactly to the value given. The definition of 'column-width'
states that the value is the optimal column width, but that the actual
column width may be different. So, 'column-width' is *honored* even if
the column width is not *exactly* equal to the length given.

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

How so?

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

I don't follow you here. Could you expand on this?

 > Hence the earlier sentence needs revising.

The note is meant to be helpful. And I believe it to be true. However,
if it's more confusing than helpful, it may be best to remove it. Is
that your suggestion?

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

So, what's your proposed change?

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

I agree that the current text:

 (a)  This allows child elements with ‘z-index’ values to be on top of column rules.

is misleading, for the reasons you give. However, your proposed text:

 (b)  ensures child elements are always painted

is also misleading: one can never ensure anything in CSS, and elements
are clipped in the middle of the column gap.

I suggest we remove (a) and do not replace it with anything.

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

What do implementors think -- do multicol elements establish new
stacking contexts?

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

That's fine, we can add that.

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

Yes.

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

I agree that is should be restricted. It should probably be expressed
in the prose. Perphaps we could change this:

    The element spans across all columns.

to

    The element spans across all columns of the nearest multicol
    ancestor of the same block formatting context.

 > 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"?

It means "specified value" and should probably be changed to just that. 

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

Indeed, it should read "... after 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.

I see your point. I'd like to keep the current example (which will
happen more often than the case you are describing) but we could add
another example. 

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

Explicit column breaks are honored, even if 'column-fill: balance' is
specified. Just like 'widows', 'orphans', margins, padding, borders
etc. are honored, even if this can disrupt balance. 

So, setting 'column-fill: balance' is more about choosing one of two
possible strategies when adding content, than to get exactly the same
column lengths. This is expressed in the paragraph:
 
  There are two strategies for filling columns: columns can either be
  balanced, or not. If columns are balanced, UAs should minimize the
  variation in column length. Otherwise, columns are filled
  sequentially and some columns may end up partially filled, or with
  no content at all. In any case, the user agent should try to honor
  the ‘widows’ and ‘orphans’ properties.

One may argue that column breaks etc. should be added to the last
sentence.

But I don't see how we can make the spec more specific.

There is also a separate discussion on the last part of 7.1.

  http://lists.w3.org/Archives/Public/www-style/2011Dec/0100.html

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

I see your argument. This would also be the case for #3: column that
end up on the next page du to explicit column break are not outside
the multicol element either.

Perhaps we could resolve both by changing:

  "A multicol element can have more columns than it has room for due to:"

to

  "A multicol element can have more columns than its first box has
  room for due to:"

although the term "first box" may not be ideal -- ":before"
pseudo-elements could get in the way. Hmm, suggestions?

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

Yes, columns widths are elastic enough to fill all available space.
(The concept of a minimal column width could possibly extend columns
halfways outside the multicol element, but those were discussed and
rejected in February.)

 > [1] http://www.w3.org/TR/CSS2/page.html#allowed-page-breaks
 > 
 > 
 > Cheers,
 > Anton Prowse
 > http://dev.moonhenge.net

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Sunday, 4 December 2011 00:51:02 UTC