- 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>
[Håkon Wium Lie:] [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. 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