RE: [css3-multicol] pseudo-algorithm

Stephen Zilles wrote:

 > I have suggested "minimum-column-width" and Sylvain has suggested
 > "adjusting the column-gap" as ways to achieve a (to us) more
 > reasonable behavior for the primary use case.

For the primary use case (flowing text into several columns), we will
never get into the part of the pseudo-algorithm we're discussing (line
16-26). That is, I believe designers will specify a preferred
'column-width' and let 'column-count' remain auto. 

  http://dev.w3.org/csswg/css3-multicol/#pseudo-algorithm

The 'column-width' property is defined to be the minimum width (the
column width will only get smaller than specified when the avilable
width is smaller). So, I believe we already *have* a mechanism in
place that "maximizes the combined outcome", to use Sylvain's
description in approach B:

 > A. As CSS properties, column-* should follow the principle of least surprise.
 > If the author specifies two properties and leaves the third auto then the
 > first two shall be honored as best as they can e. The suitability of the outcome
 > to the content being laid out is none of our business. 
 > 
 > B. Since multicol elements exist to address a scenario that single content 
 > box elements cannot deal with, and since they flow their content in multiple
 > boxes within the same element, they are far more sensitive to changes in available
 > width and overconstrained cases. So much so we might want to consider extra 
 > properties (min-column-*) and/or a default behavior that maximizes the combined 
 > outcome of all column properties rather than simply obtaining individual computed 
 > values equal or as close as possible to what the author specified.

Lines 16-24 is there to handle cases when 'column-width' is auto and
'column-count' is set. This will not be the most common case, and we
shouldn't really encouage its use -- unless author really wants a
specific number of columns. In this case, I do think we should "follow
the principle of least surprise" and not try to make advanced
adjustments which may or may not be what the user/author/designer
wants. Brad's likening of 'padding' to 'column-gap' is a good one.

For this algorithm, we have three options that I can live with:

1) keep the current algorithm
2) revise line 24 (by adding 1)
3) always honor column-count

After reading Brad's arguments, I'm leaning towards 3.

If others want more intelligent handling of the "common use case",
changes to lines 27-41 should be proposed.

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

Received on Monday, 14 February 2011 13:16:49 UTC