- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Wed, 16 Feb 2011 03:36:09 +0000
- To: Håkon Wium Lie <howcome@opera.com>, Brad Kemper <brad.kemper@gmail.com>
- CC: Stephen Zilles <szilles@adobe.com>, "www-style@w3.org" <www-style@w3.org>

[Håkon Wium Lie:] > However, it seems that Sylvain prefers the current algorithm. And I think > the current algorithm, having reached CR, should have precedence unless we > find consensus around another proposal. I 'prefer' it as the least bad given that I find the others to be worse. I mostly prefer it because your proposal - reflected in the Editor's Draft [1] - results in a poor, discontinuous result: when the available width shrinks to ((column-count-1)*column-gaps) we get column-width:0 and no content. Shrink your window further and now columns start reappearing. Then they disappear again. Let's use the following values as inputs: column-count:8; column-gap:50px; column-width:auto; We know that starting at 350px of available width and below we run lines (24) and (25) of the algorithm: (24) N := floor(available-width/column-gap) + 1; (25) W := (available-width - ((N - 1) * column-gap))/N; (N and W become the computed values of column-count and column-width respectively) So here are the values of N and W at different available-widths: ! 350px ! 349px ! 325px ! 300px ! 275px ! 250px ! 225px ! 200px ! ---!-------!-------!-------!-------!-------!-------!-------!-------! N ! 8 ! 7 ! 7 ! 7 ! 6 ! 6 ! 5 ! 5 ! ---!-------!-------!-------!-------!-------!-------!-------!-------! W ! 0px ! 7px ! 3.6px ! 0px ! 4.2px ! 0px ! 5px ! 0px ! ---!-------!-------!-------!-------!-------!-------!-------!-------! So while the decrease in N could be called smoother the result is column content popping in and out of existence. I don't understand why that's desirable. Using the current algorithm in the WD [2] instead, we have: (24) N := floor(available-width/column-gap); (25) W := (available-width - ((N - 1) * column-gap))/N; Which gives us: ! 350px ! 349px ! 325px ! 300px ! 275px ! 250px ! 225px ! 200px ! ---!-------!-------!-------!-------!-------!-------!-------!-------! N ! 7 ! 6 ! 6 ! 6 ! 5 ! 5 ! 4 ! 4 ! ---!-------!-------!-------!-------!-------!-------!-------!-------! W ! 7.1px ! 16.5px! 12.5px! 8.3px ! 15px ! 10px ! 18.7px! 12.5px! ---!-------!-------!-------!-------!-------!-------!-------!-------! In this case, the column-width shrinks with the available width then pops back up when the column count is decreased but that is OK imo; given column-width:auto, decreasing column-count temporarily increases the widths of the remaining columns. Note, however, that these column-width values are not practically usable for text at common body text font sizes. My preference would be to apply a tighter constraint on the column gaps test in the algorithm e.g. to half the available width: /* The //! marks those lines that differ from the WD [2] */ if (column-width = auto) then if ( (column-count-1) * column-gap < (available-width/2) then //! N := column-count; W := (available-width - ((N - 1) * column-gap))/N; elsif (column-gap >= available-width) then N := 1; W := available-width; else N := floor((available-width/2)/column-gap); //! W := (available-width - ((N - 1) * column-gap))/N; fi .... Plugging the previous numbers back in and expanding the range to account for the new column-gap constraint we get: ! 700px ! 600px ! 500px ! 400px ! 350px ! 300px ! 250px ! 200px ! ---!-------!-------!-------!-------!-------!-------!-------!-------! N ! 7 ! 6 ! 5 ! 4 ! 3 ! 3 ! 2 ! 2 ! ---!-------!-------!-------!-------!-------!-------!-------!-------! W ! 57.1px! 58.3px! 60px! 62.5px! 83.3px! 66.7px! 100px ! 75px ! ---!-------!-------!-------!-------!-------!-------!-------!-------! While the number of columns drops earlier, it drops progressively. The total surface available for content is also much higher. Assuming a 300px height, this version yields 45,000 square pixels of column box surface at available-width:200px; using the current WD we get 15,000 sq.px or a loss of content space of 2/3. The specified column-gap is respected throughout (thus preserving the padding-like expectation) but column-count is adjusted to ensure that said padding never occupies more than half the available space to the detriment of content. I think such a result is in line with the primary use-case for the feature : laying out text columns. I can't judge the suitability of this algorithm against unspecified, hypothetical 'exotic' scenarios, of course. But I believe it would handle overconstrained situations better for text content than what we currently have by producing a more usable result for a wider range of available width values. This is not a formal proposal but is meant to clarify what I think the behavior should be like for column-width:auto vs. current Working and Editor's Drafts. [1] http://dev.w3.org/csswg/css3-multicol/#pseudo-algorithm [2] http://www.w3.org/TR/css3-multicol/#pseudo-algorithm

Received on Wednesday, 16 February 2011 03:36:42 UTC