W3C home > Mailing lists > Public > www-style@w3.org > February 2011

RE: [css3-multicol] pseudo-algorithm

From: Håkon Wium Lie <howcome@opera.com>
Date: Mon, 14 Feb 2011 14:16:03 +0100
Message-ID: <19801.11027.102965.281164@gargle.gargle.HOWL>
To: Stephen Zilles <szilles@adobe.com>, Brad Kemper <brad.kemper@gmail.com>, Sylvain Galineau <sylvaing@microsoft.com>, "www-style@w3.org" <www-style@w3.org>
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 GMT

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