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