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/howcomeReceived on Monday, 14 February 2011 13:16:49 UTC
This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:56 UTC