RE: [css3-multicol] pseudo-algorithm

[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