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: Mon, 14 Feb 2011 23:43:19 +0100
Message-ID: <19801.45063.557130.374529@gargle.gargle.HOWL>
To: Sylvain Galineau <sylvaing@microsoft.com>
Cc: Håkon Wium Lie <howcome@opera.com>, Stephen Zilles <szilles@adobe.com>, Brad Kemper <brad.kemper@gmail.com>, "www-style@w3.org" <www-style@w3.org>
Sylvain Galineau wrote:

 > [sylvaing] 
 > > Lines 16-24 is there to handle cases when 'column-width' is auto and
 > > 'column-count' is set. 
 > To be exact, the 24-25 branch handles the case where column-width is auto,
 > column-count is specified and the total size of column-gaps is larger than
 > the available width. So while I would agree this is generally not the kind
 > of constraint one aims at in a design (modulo the more creative and exotic
 > things people might do with multicols, as pointed out by Brad) it is a 
 > fallback of the primary use-case. 

The primary use case is best handled by setting 'column-width' to a
value other than auto. And then we will not get into this part of the

 > One that could be triggered by something as simple as the viewport
 > being resized to half its size by the window manager. As specified,
 > I think the current fallback pretty much forces the author to
 > define a media query to handle the result.

Media queries is an option. But setting 'column-width' is easier.

 > >This will not be the most common case, and we
 > > shouldn't really encouage its use -- unless author really wants a specific
 > > number of columns. 
 > Experience indicates that 'encouragements' have limited influence on what 
 > authors do in practice.

Sure. But if they chose to set column-count and column-gap to specific
values, perhaps they mean it?

 > >In this case, I do think we should "follow the
 > > principle of least surprise" and not try to make advanced adjustments
 > > which may or may not be what the user/author/designer wants. Brad's
 > > likening of 'padding' to 'column-gap' is a good one.
 > It's hard to argue that this is both a fallback scenario - i.e. not the primary
 > use-case - *and* what the designer wants. 

In a few cases this will be what the designer wants. 

 > > For this algorithm, we have three options that I can live with:
 > > 
 > > 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.

3) could be expressed as:

    if (column-width = auto) then
        N := column-count;
        W := max(0, (available-width - ((N - 1) * column-gap))/N);

So, 'column-width' would work as 'width', and 'column-gap' would work
as 'padding'.

What's your preferred solution?

              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Monday, 14 February 2011 22:44:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:56 UTC