W3C home > Mailing lists > Public > www-style@w3.org > February 2011

RE: [css3-multicol] pseudo-algorithm

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Mon, 14 Feb 2011 21:54:07 +0000
To: 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>
Message-ID: <045A765940533D4CA4933A4A7E32597E2AB5E756@TK5EX14MBXC120.redmond.corp.microsoft.com>

[Håkon Wium Lie:]

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

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

>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. The issue here is that while the
values of the individual properties involved does follow the principle of least
surprise, the end-result may still be judged to be surprisingly poor. Put another
way, the behavior of each of these properties may be argued to follow the 80/20 rule
but their interaction during fallback produces a .8 x .8 x .8 result.

> 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.
Received on Monday, 14 February 2011 21:54:41 UTC

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