W3C home > Mailing lists > Public > www-style@w3.org > February 2011

RE: [css3-multicol] pseudo-algorithm

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Wed, 16 Feb 2011 17:26:03 +0000
To: Brad Kemper <brad.kemper@gmail.com>
CC: Håkon Wium Lie <howcome@opera.com>, Stephen Zilles <szilles@adobe.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E2AB5FA09@TK5EX14MBXC120.redmond.corp.microsoft.com>
[Brad Kemper:]
> I wish the "pseudo-algorithm" was explained in the spec in clear English.
> I didn't realize before this thread (mostly because I find it hard to read
> and make sense of that algorithm) that the number of columns could be less
> than what the author asked for, even though he has indicated that the
> width should be automatically sized to allow it. I find it strange that an
> author could ask for 8 columns and end up with 4, and that there is
> nothing he can do about that, short of having a media query that changes
> the gap size.

Well, fwiw, I find pseudo-algorithms way clearer than prose :) 

The reason the column-count has to come down is that there is no other way
in an overconstrained situation. Especially so if we consider column-gap 
to be like padding. The branch of the algorithm being discussed deals with 
the following scenario: the available width is not large enough to fit all 
the column gaps for the column-count specified by the author. So not only 
can't you get any content in that space anymore but, even though it looks 
the same, you can't fit that number of columns either. You just have more 
of everything - content and gaps - than can fit.

So columns get dropped. I think that's a generally reasonable behavior for 
multicolumn text. Once column-width is auto and the layout is overconstrained
then either content goes away - the worst outcome imo - or one of the other
variables is treated as a max value. If column-gap can't change then column-count
takes the hit.
Received on Wednesday, 16 February 2011 17:26:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:56 UTC