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