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: Thu, 10 Feb 2011 15:21:00 +0100
Message-ID: <19795.62540.883976.762113@gargle.gargle.HOWL>
To: Sylvain Galineau <sylvaing@microsoft.com>
Cc: Stephen Zilles <szilles@adobe.com>, Håkon Wium Lie <howcome@opera.com>, Alex Mogilevsky <alexmog@microsoft.com>, "www-style@w3.org" <www-style@w3.org>
Also sprach Sylvain Galineau:

 > Let's try a simple 'normal' use-case. 
 > 
 > Say we have 600px of available width.
 > column-count is 4.
 > column-width is auto.
 > column-gap is 20px.
 > 
 > If I read the algorithm correctly we'd end up with 4 columns of 
 > 135px. 

Correct.

 > I can see the argument for the result: the author did 
 > specify a column-gap size but kept the column-width auto so 
 > we honored what was specified.

Yes. 

 > Whether 135px is enough or better than the maximum 150px that
 > could be achieved by shrinking the specified gap really is
 > a function of the content, font size etc. 
 > 
 > So on the basis of this 'reasonable' use-case I'd qualify my 
 > earlier statement by saying the algorithm gives priority to 
 > those constraints that are specified by the author. Which does 
 > seem quite reasonable in such cases.

Yes.

 > Now if we try something that gets us to (24):
 > 
 > Available width is 600px.
 > column-width is auto.
 > column-count is 6.
 > column-gap is 125px.
 > 
 > The current algorithm gives us 
 > 
 > N := floor(available-width/column-gap) == floor(600px/125px) == 4 columns
 > W := (available-width - ((N - 1) * column-gap))/N == (600px - (3*125px))/4 == 56.25px columns
 > 
 > Hakon's suggested change yields N:=5 and thus W:= (600px - (4*125px))/5 == 20px i.e. more, 
 > but much narrower columns.

Yes.

 > So while we're squeezing in one more column, we're also getting a lot less content into
 > the multicol element. Let's assume our multicol element's height is also 600px. In the 
 > current algorithm we get 4 columns of size 56.25px by 600px, for a total 'content surface'
 > of 135,000 pixels.
 > 
 > In the new algorithm, we have 5 columns 20px by 600px or 60,000px of 'content surface'.
 > Which makes sense since adding a column also adds 110px of white space which, substracted
 > over a small number of already thin columns, takes a big chunk out of them. 

I've run a simulation to compare the two. In the results below, I go
from 1200 to 0 in width. The resulting number of columns and their
widths are shown in the comments to the right (with a "/" between
them:

width: 1200; column-gap: 125; column-count: 6; /* current: 6/95 revised 6/95 */
width: 1180; column-gap: 125; column-count: 6; /* current: 6/92 revised 6/92 */
width: 1160; column-gap: 125; column-count: 6; /* current: 6/89 revised 6/89 */
width: 1140; column-gap: 125; column-count: 6; /* current: 6/85 revised 6/85 */
width: 1120; column-gap: 125; column-count: 6; /* current: 6/82 revised 6/82 */
width: 1100; column-gap: 125; column-count: 6; /* current: 6/79 revised 6/79 */
width: 1080; column-gap: 125; column-count: 6; /* current: 6/75 revised 6/75 */
width: 1060; column-gap: 125; column-count: 6; /* current: 6/72 revised 6/72 */
width: 1040; column-gap: 125; column-count: 6; /* current: 6/69 revised 6/69 */
width: 1020; column-gap: 125; column-count: 6; /* current: 6/65 revised 6/65 */
width: 1000; column-gap: 125; column-count: 6; /* current: 6/62 revised 6/62 */
width: 980; column-gap: 125; column-count: 6; /* current: 6/59 revised 6/59 */
width: 960; column-gap: 125; column-count: 6; /* current: 6/55 revised 6/55 */
width: 940; column-gap: 125; column-count: 6; /* current: 6/52 revised 6/52 */
width: 920; column-gap: 125; column-count: 6; /* current: 6/49 revised 6/49 */
width: 900; column-gap: 125; column-count: 6; /* current: 6/45 revised 6/45 */
width: 880; column-gap: 125; column-count: 6; /* current: 6/42 revised 6/42 */
width: 860; column-gap: 125; column-count: 6; /* current: 6/39 revised 6/39 */
width: 840; column-gap: 125; column-count: 6; /* current: 6/35 revised 6/35 */
width: 820; column-gap: 125; column-count: 6; /* current: 6/32 revised 6/32 */
width: 800; column-gap: 125; column-count: 6; /* current: 6/29 revised 6/29 */
width: 780; column-gap: 125; column-count: 6; /* current: 6/25 revised 6/25 */
width: 760; column-gap: 125; column-count: 6; /* current: 6/22 revised 6/22 */
width: 740; column-gap: 125; column-count: 6; /* current: 6/19 revised 6/19 */
width: 720; column-gap: 125; column-count: 6; /* current: 6/15 revised 6/15 */
width: 700; column-gap: 125; column-count: 6; /* current: 6/12 revised 6/12 */
width: 680; column-gap: 125; column-count: 6; /* current: 6/9 revised 6/9 */
width: 660; column-gap: 125; column-count: 6; /* current: 6/5 revised 6/5 */
width: 640; column-gap: 125; column-count: 6; /* current: 6/2 revised 6/2 */
width: 620; column-gap: 125; column-count: 6; /* current: 4/61 revised 5/24 */
width: 600; column-gap: 125; column-count: 6; /* current: 4/56 revised 5/20 */
width: 580; column-gap: 125; column-count: 6; /* current: 4/51 revised 5/16 */
width: 560; column-gap: 125; column-count: 6; /* current: 4/46 revised 5/12 */
width: 540; column-gap: 125; column-count: 6; /* current: 4/41 revised 5/8 */
width: 520; column-gap: 125; column-count: 6; /* current: 4/36 revised 5/4 */
width: 500; column-gap: 125; column-count: 6; /* current: 4/31 revised 5/0 */
width: 480; column-gap: 125; column-count: 6; /* current: 3/76 revised 4/26 */
width: 460; column-gap: 125; column-count: 6; /* current: 3/70 revised 4/21 */
width: 440; column-gap: 125; column-count: 6; /* current: 3/63 revised 4/16 */
width: 420; column-gap: 125; column-count: 6; /* current: 3/56 revised 4/11 */
width: 400; column-gap: 125; column-count: 6; /* current: 3/50 revised 4/6 */
width: 380; column-gap: 125; column-count: 6; /* current: 3/43 revised 4/1 */
width: 360; column-gap: 125; column-count: 6; /* current: 2/117 revised 3/36 */
width: 340; column-gap: 125; column-count: 6; /* current: 2/107 revised 3/30 */
width: 320; column-gap: 125; column-count: 6; /* current: 2/97 revised 3/23 */
width: 300; column-gap: 125; column-count: 6; /* current: 2/87 revised 3/16 */
width: 280; column-gap: 125; column-count: 6; /* current: 2/77 revised 3/10 */
width: 260; column-gap: 125; column-count: 6; /* current: 2/67 revised 3/3 */
width: 240; column-gap: 125; column-count: 6; /* current: 1/240 revised 2/57 */
width: 220; column-gap: 125; column-count: 6; /* current: 1/220 revised 2/47 */
width: 200; column-gap: 125; column-count: 6; /* current: 1/200 revised 2/37 */
width: 180; column-gap: 125; column-count: 6; /* current: 1/180 revised 2/27 */
width: 160; column-gap: 125; column-count: 6; /* current: 1/160 revised 2/17 */
width: 140; column-gap: 125; column-count: 6; /* current: 1/140 revised 2/7 */
width: 120; column-gap: 125; column-count: 6; /* current: 1/120 revised 1/120 */
width: 100; column-gap: 125; column-count: 6; /* current: 1/100 revised 1/100 */
width: 80; column-gap: 125; column-count: 6; /* current: 1/80 revised 1/80 */
width: 60; column-gap: 125; column-count: 6; /* current: 1/60 revised 1/60 */
width: 40; column-gap: 125; column-count: 6; /* current: 1/40 revised 1/40 */
width: 20; column-gap: 125; column-count: 6; /* current: 1/20 revised 1/20 */
width: 0; column-gap: 125; column-count: 6; /* current: 1/0 revised 1/0 */

In both cases, we will have to deal with very narrow colunmns. For
example, at width 640, all columns have a width of 2. One striking
difference between the two is that in the current algorithm, the
column widths will actually increase as the width decreases. For
example, at width 360, the current algorighm gives us columns widths
of 117 -- significantly larger than 95 which is where we started
(admittedly, 1200 is an arbitrary starting point. But if we use
pixels, few pages are wider).

 > As the proposed change increases the gap/content ratio, I'm not so sure I agree with
 > it anymore :( But I'm also wondering whether we should be treating column-gap as a max 
 > width and aim for the column-count closest to the author's request. It would be more 
 > complex but it might yield better results more often ?

I doubt that there's much to gain. Column gaps will, in typical
paper-based usage, not be very wide and there's little to be gained by
poaching. 

However, I agree it's one of the options. Let's try list the options:

1) keep the current algorithm

   + easy
   - gives us abrupt changes (6 -> 4) in #columns

2) revise line 24 (by adding 1)

   + no abrupt changes in #columns
   + more consistant column widths
   - more situations where columns are narrow

3) always honor column-count

   + that'll teach'em
   + easy
   - more situationw where column widths are zero

4) go to 1 column as soon as column-width reaches zero

   + easy
   - abrupt chance

5) try adjust column-gap as the width decreases

   + smooth, if we find the right formula
   - complex?
   - doesn't honor 'column-gap'

6) introduce min-column-width (probably in combination with 2)

   + fewer narrow columns
   - would bring us back to last call
   - more complex to implement
   - there would still be lots of clipping

Any other options?

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Thursday, 10 February 2011 14:21:40 GMT

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