- From: Håkon Wium Lie <howcome@opera.com>
- Date: Sun, 15 Sep 2013 18:57:42 +0200
- To: www-style@w3.org
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