W3C home > Mailing lists > Public > www-style@w3.org > January 2012

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

From: Håkon Wium Lie <howcome@opera.com>
Date: Mon, 9 Jan 2012 20:10:20 +0100
Message-ID: <20235.15260.498267.228407@gargle.gargle.HOWL>
To: Anton Prowse <prowse@moonhenge.net>
Cc: "www-style@w3.org" <www-style@w3.org>
Anton Prowse wrote:

 [long discussion deleted]
  
 > > Given all this, perhaps you could come up with a revised proposal?
 > 
 > I think "block containers" is the tidiest option, and the one most 
 > likely to be correct when other specs introduce new box types that are 
 > apt for being multicol boxes.

The editor's draft has now replaced:

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

with:

  "Column boxes are block container boxes."

This is what you suggested, right? Also, the subsequent text has been
changed to match the new wording:

  Column boxes are block container boxes. 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 block container boxes for elements with ''position:
  fixed'' or ''position: absolute''. 

Is this correct?

 > >>  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?
 > 
 > The third paragraph of Section 2 begins:
 > 
 >    # Column boxes in a multi-column element are arranged into rows.
 > 
 > I would prepend the following sentence:
 > 
 >    | A column box is a non–inline-level block container box.
 > 
 > An alternative is to state in 3.5 that column boxes are painted on the 
 > layer for "in-flow non–inline-level non-positioned boxes" [CSS21, 
 > 9.2.1]; but of course that's only true if the column box is indeed 
 > in-flow and non-positioned, something which is necessarily true right 
 > now but who knows in future.  Hence this alternative is more error-prone.

Hm. Wouldn't it be better to describe this in the "Stacking context"
section? And, while it's true that we may want to make columns more
powerful in the future, shouldn't we try to keep this specification as
simple as possible while remaining interally consistent?

 > >>  Also, it seems to be the intention that column boxes do not necessarily
 > >>  establish new stacking contexts; this needs to be stated explicitly.
 > 
 > Is this the intention?  (It seems reasonable.)

Any objection from implementors? I've added this to the editor's draft:

  Column boxes do not establish new stacking contexts.

If we later decide to make columns more powerful (e.g., by positioning
them) this is not necessarily true anymore. But I think we can worry
about that later.

 > Another small nit: The sentence that precedes (a) is
 > 
 >    # If a column rule is wider than its gap, the column rule will
 >    # overlap adjacent column boxes, and possibly extend outside the box
 >    # of the multicol element.
 > 
 > I'm not sure that "overlap" is a good choice of word given that the 
 > column rules lie under the column boxes as currently specified.  Perhaps 
 > we could turn that clause around:
 > 
 >    | If a column rule is wider than its gap, the adjacent column boxes
 >    | will overlap the rule, and the rule may possibly extend outside the
 >    | box of the multicol element.

Good, inserted. 

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

Added.

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

Done.

 > >>  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.
 > 
 > Possibly s/ancestor of/ancestor in/ but OK.

Done.

 > >>  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.
 > 
 > OK.  Let's do that.

Done.

 > >>  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 ...".
 > 
 > This doesn't make any more sense to me!  I think it should be "in the 
 > fourth A-z string" or somesuch. (Some of the A-z strings are subdivided 
 > into two sentences.)  Or possibly:
 > 
 > s/after the first sentence in the fourth sentence/after the sixth sentence/

You are right. I should practice counting sentences more often. Fixed.

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

Added.

I've also added an exmple that shows how spanners are kept in paged mode.

 > >>  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.
 > 
 > I do think it would be useful to mention them:
 > 
 >    | In any case, the user agent must honor forced breaks and forced
 >    | break avoidance, and should try to honor the ‘widows’ and ‘orphans’
 >    | properties.
 > 
 > (Note that the spec wording makes it seem like forced column breaks and 
 > forced break avoidance are mandatory.  If that's not the case then the 
 > spec needs to say so and the proposed sentence above obviously needs 
 > tweaking.)

I don't think we can mandate forced break avoidance. A very long
paragraph with 'break-inside: avoid' must be broken at some point.

I've reworded the sentence to say:

  In any case, user agents must honor forced page breaks and should
  try to honor 'widows', 'orphans' and other properties that may
  affect column lengths.

 > > 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
 > 
 > OK, I agree that "If columns are balanced, UAs should minimize the 
 > variation in column length." is pretty clear about the intent.  But is 
 > it true that reducing the number of overflow columns wins over the need 
 > for balance (and in particular no balancing is attempted whatsoever if 
 > the number of column breaks in an unconstrained multicol in continuous 
 > media contains a number of column breaks equal or greater than one fewer 
 > than the number of non-overflow columns)?
 > 
 > I think that the spec should modify the sentence just mentioned to 
 > achieve something like the following:
 > 
 >    | If columns are balanced, UAs should minimize the variation in
 >    | column length subject to avoiding overflow columns if possible and
 >    | minimizing the content in overflow columns otherwise. 
 > 
 > Another issue though: "variation in column length" isn't the right 
 > phrase, because columns in the same row are always of equal length. It's 
 > the content height that can vary.

Yes. Hmm. I suggest:

  If columns are balanced, user agents should try to fill all columns
  in a row so that the columns appear to have the same amount of
  content, while also trying to minimize the overflow content.

 > >>  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?
 > 
 > I think we may need to rewrite this section a little.  I was about to 
 > suggest a rewording when I realized that I'm not clear about the 
 > behaviour of column breaks in paged media.  Example XXV is useful, but I 
 > can't tell if it shows a special case in which content reaches the 
 > bottom of the first page in the second column box or whether there's an 
 > empty vertical space in the page box below that column box.  That is, 
 > what happens if the multicol element is at the top of the first page but 
 > is eligible for splitting to the second page?  Would there be three 
 > columns of page box height on the first page, each only partially full, 
 > with more column boxes on the next page (possibly overflowing if the 
 > multicol isn't eligible for splitting onto a further page)?

In paged mode, there are always more pages available so content would
never overflow like in Example XXIII or Example XXIV.

So, yes, there would be three columns on the first page, each only
partially full (due to forced column breaks) with more column boxes on
the next page (and subsequent pages.)

 > Or would 
 > the multicol be allowed to split onto the second page after the first 
 > three column breaks, leaving a blank vertical space below the first 
 > fragment of the multicol box on the first page, with more column boxes 
 > on the next page (possibly overflowing if the multicol isn't eligible 
 > for splitting onto a further page)? 

Yes. I don't see the difference between your first option and the
second option. Both seem correct to me.

 > Or would the multicol be allowed to 
 > overflow in the inline direction on the first page?  I get the 
 > impression that the latter is only permitted when the multicol is 
 > constrained, but what if the constraint is such that the multicol may 
 > still split across pages: is it only the last multicol box fragment 
 > (that appears on the last page) that may overflow in the inline direction?

Overflow in the inline direction only happens in continuous
media; in paged media overflow column go onto the next page(s)
instead. This is described by this text:

  .. additional column boxes are created in the inline
  direction for continous media, and additional column boxes are moved
  to the next page(s) for paged media.

 > Let's return to reworking 8.2 once I'm clearer about the behaviour above.

Ok, let me know if you have suggestions.

When reviewing this, I have revised Example XXV slightly: columns are
balanced by default, so it's better to show three columns with content
on the second page.

Also I've added more examples. 

 > [Note that the word "continuous" is spelt incorrectly twice in 8.2, as I 
 > noticed when pasting into this e-mail!]

Whoops. Fixed. 

The new editor's draft is here:

  http://dev.w3.org/csswg/css3-multicol/

Again, thanks for your extensive review and suggestions.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Monday, 9 January 2012 19:11:24 GMT

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