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: Tue, 15 Feb 2011 21:10:41 +0100
Message-ID: <19802.56769.455358.103155@gargle.gargle.HOWL>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: Sylvain Galineau <sylvaing@microsoft.com>, Stephen Zilles <szilles@adobe.com>, "www-style@w3.org" <www-style@w3.org>
Also sprach Brad Kemper:

 > >>> 1) keep the current algorithm
 > >>> 2) revise line 24 (by adding 1)
 > >>> 3) always honor column-count
 > >>> 
 > >>> After reading Brad's arguments, I'm leaning towards 3.
 > >> 
 > >> I don't see how 3 is doable since this specific branch of the algorithm 
 > >> deals with the case where there isn't enough room for the column gaps implied 
 > >> by column-count i.e. the only way to make everything add up would be to make
 > >> the column-widths negative.
 > The way I see it, is that we could:
 > A) Not let the width of the multicol element be less that the total
 > of all its column gaps, but columns widths can be auto-sized down
 > to zero. This is what life is like in the DTP page design world.
 > Or...

Yes, this is how I think about 3)

 > B) Once columns become zero and the multicol element is too narrow
 > to fit all the gaps, then start reducing the gap width.

I don't like this; it complicates the algorithm and there's little to
gain from narrow gaps.

 > I think I would be fine with either one. Since the gap reduction in
 > "B" is really, really a last resort of the UA to honor the multicol
 > width, it is not too surprising, and still allows zero width
 > columns to be equally spaced. But since we are usually talking
 > about 'width:auto' making the multicol narrow, so "A" has an appeal
 > to me too (the width "auto"-matically does not get narrower than
 > all the gaps).
 > A.2) would be letting the gaps overflow the multicol.

That's also an option, yes.

However, it seems that Sylvain prefers the current algorithm. And I
think the current algorithm, having reached CR, should have
precedence unless we find consensus around another proposal.

              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Tuesday, 15 February 2011 20:11:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:55 UTC