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

RE: [css3-multicol] pseudo-algorithm

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Wed, 16 Feb 2011 19:34:51 +0000
To: Brad Kemper <brad.kemper@gmail.com>
CC: Håkon Wium Lie <howcome@opera.com>, Stephen Zilles <szilles@adobe.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E2AB5FC12@TK5EX14MBXC120.redmond.corp.microsoft.com>
[Brad Kemper:]
> I'm not sure it is. With the current algorithm, I can't guarantee the
> number of columns would be as specified, right, unless we introduce
> 'column-count-I-really-man-it'? 

You cannot guarantee it when the container has a variable width and 
column-width is auto. If the column gaps are fixed and the available 
width is too narrow to fit them then you *cannot* have  the number of 
columns you asked for. It'll look like you do today - if your implementation
conforms to the pseudo-algorithm - because the result looks the same 
courtesy of column-width:0; but if, maybe, we were to add the ability 
to decorate gaps somehow or select individual columns you'd find you
don't have all the columns you ask for.

> That is the main thing I am arguing
> against, not whether or not gaps should be reduced in over-constrained
> situations (I'm still ambivalent about that one).

I know. But you're arguing potential against the well-known and well-
understood scenario multicols are designed to address. The predictability
of the hypothetical is a pretty hard thing to measure :)

> 
> > Not only am I unable to
> > understand why I should prioritize
> 
> "allow", not "prioritize"...

It's not disallowed. The mainline scenario works well for column-width:auto,
the odd ones may require fixed width and/or explicit column-widths. 
Making the primary use-case work well by default and require extra work
for stuff nobody can think of today is not unreasonable imo.

> 
> > unknown scenarios at the same level as the primary use-case, but I
> > have no way - by definition - to assert that the current algorithm or
> > your preferred behavior will work well for them either.
> 
> I'm fir the principle of least surprise.

I am too. But we disagree on which level of surprise matters most. You
think changing the computed value of column-count in constrained cases
is surprising. I'm far more concerned about authors and users being 
surprised by what happens in a fluid multi-column design when they snap 
their browser window and end up with a poor result. Never mind content 
disappearing entirely, or worse, popping in and out of view. It'll simply
make them avoid auto entirely. Some people may argue that's good because 
auto shouldn't be used; if that's so then I'd argue against supporting it 
at all.


> > At the very least, I strongly object to a default behavior that causes
> > content to appear/disappear/re-appear as available width changes.
> 
> Agreed.
Received on Wednesday, 16 February 2011 19:35:29 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:37 GMT