- From: Håkon Wium Lie <howcome@opera.com>
- Date: Tue, 15 Feb 2011 21:10:41 +0100
- 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 Håkon Wium Lie CTO °þe®ª howcome@opera.com http://people.opera.com/howcome
Received on Tuesday, 15 February 2011 20:11:25 UTC