RE: [css3-multicol] pseudo-algorithm

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. 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.

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.

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.

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. 

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 ?






> -----Original Message-----
> From: Stephen Zilles [mailto:szilles@adobe.com]
> Sent: Tuesday, February 08, 2011 11:26 AM
> To: Håkon Wium Lie; Sylvain Galineau
> Cc: Alex Mogilevsky; www-style@w3.org
> Subject: RE: [css3-multicol] pseudo-algorithm
> 
> Keeping the algorithm simple at the cost of having really bad
> presentations hardly seems like the right trade-off. Most CSS fallbacks
> have focused on doing something reasonable with unreasonable inputs, such
> as column-count: 999999.
> 
> Steve Zilles
> 
> 
> > -----Original Message-----
> > From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
> > Behalf Of Håkon Wium Lie
> > Sent: Tuesday, February 08, 2011 11:18 AM
> > To: Sylvain Galineau
> > Cc: Alex Mogilevsky; www-style@w3.org
> > Subject: RE: [css3-multicol] pseudo-algorithm
> >
> > Also sprach Sylvain Galineau:
> >
> >  > I was wondering about that. Taking another look  > at this branch
> > of the algorithm it certainly seems  > to be designed to preserve the
> > specified column-gap,
> >
> > The whole algorithm is -- and has always been -- partial to
> > 'column-gap'; it may give new values to 'column-width' and
> > 'column-count', but not to 'column-gap'. This is good, I believe. It
> > keeps the algorighm (relatively) simple, and column gaps will
> > typically be narrow so there isn't much space to gain by reducing
> > their width.
> >
> > -h&kon
> >               Håkon Wium Lie                          CTO °þe®ª
> > howcome@opera.com                  http://people.opera.com/howcome
>

Received on Tuesday, 8 February 2011 20:20:12 UTC