- 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