Re: [css-multicol] remaining issues

Here's an update on the multicol spec discussions at the recent F2F. 

 > I'm preparing for the CSS f2f meeting where I hope to resolve all the
 > remaining multicol issues. I my head, I find only three of those:
 > 
 > 1) the clipping issue
 > 
 >      http://lists.w3.org/Archives/Public/www-style/2013Mar/0057.html
 >      http://lists.w3.org/Archives/Public/www-style/2013Aug/0269.html
 > 
 >    It seems we can go in two directions: more clipping or less
 >    clipping. I leaning towards less clipping:
 > 
 >      http://lists.w3.org/Archives/Public/www-style/2013Aug/0526.html

The WG discussed clipping. The sentiment was that clipping for
multicol elements should be as similar to other elements as possible.
Clipping mid-column, which the LC document prescribes, is therefore
problematic (especially for (say) images that overflow into the next
column as well as beyond the border of the multicol element). So, this
resolution was reached:

  RESOLVED: Columns do not clip anything. (As if ::column just had overflow:visible by default.)

  http://logs.csswg.org/irc.w3.org/css/?date=2013-09-11

 > 2) 'column-fill: auto' in unconstrained environments
 > 
 >    I suggest we should honor 'column-fill: auto' in unconstrained
 >    enviroments, thereby relying on explicit column breaks to break
 >    columns:
 > 
 >      http://lists.w3.org/Archives/Public/www-style/2011Dec/0455.html
 >      http://lists.w3.org/Archives/Public/www-style/2013Aug/0274.html
 >      http://lists.w3.org/Archives/Public/www-style/2013Aug/0304.html

Noone argued against honoring 'column-fill: auto' in unconstrained environments:

  <TabAtkins> howcome: So it sounds like we have agreement that we should honor column-fill even in unconstrained environments.

  http://logs.csswg.org/irc.w3.org/css/?date=2013-09-11

It should be marked as resolved in the minutes.

 > 3) z-order of column-rule: below or above border
 > 
 >    I suggest we specify that "Column rules are painted in the inline
 >    content layer; below all inline content inside the multicol element,
 >    but above the border of the multicol element."
 > 
 >      http://lists.w3.org/Archives/Public/www-style/2013Aug/0223.html
 >      http://lists.w3.org/Archives/Public/www-style/2013Aug/0531.html
 >      http://lists.w3.org/Archives/Public/www-style/2013Sep/0006.html

Rossen commented on this; no change seems necessary:

  http://lists.w3.org/Archives/Public/www-style/2013Sep/0195.html

The topic that we spend the most time on was column balancing. There
was agreement that we should have one keyword to specify that all
pages should be balanced, and another keyword to specify that only the
last page should be balanced. These keywords seemed reasonable:

  balance-last
  balance-all

However, the 'balance' keyword should remain (it's the initial value),
so the qeustion becomes: do we prefer this set of keywords:

  balance-last
  balance       /* balance all */

or this set?:

  balance-all
  balance      /* balance last page only */

It was decided to resolve this by looking at implementations:

   <TabAtkins> RESOLVED: Have two keywords for balancing - "balance" and either "balance-last" or "balance-all", depending on what implementions (including Prince and AH) do by default.

It seems that both AH and PR do not balance all pages by default:

  http://people.opera.com/howcome/2013/tests/multicol/column-fill-ah.pdf
  http://people.opera.com/howcome/2013/tests/multicol/column-fill-pr.pdf
  http://people.opera.com/howcome/2013/tests/multicol/column-fill.html

It seems Opera/Presto also does it this way. 

I therefore suggest we choose these keywords:

  balance-all
  balance      /* balance last page only */

So that documents, by default, only balance the last page.

----

We also discussed how balancing should work:

  [08:01] <TabAtkins> RESOLVED: To balance columns, you just make the row as short as possible (honoring breaks, sizes, etc.), then flow normally into that height. No explicit "balancing" occurs (but it's a common effect).

It should be added that avoiding overflow columns is also a goal. I'll propose text to this effect.

--

Given the changes, it seems clear that the specification must go back
to Last Call.

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

Received on Sunday, 15 September 2013 16:58:16 UTC