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

Re: [css3-multicol] pseudo-algorithm

From: Brad Kemper <brad.kemper@gmail.com>
Date: Fri, 11 Feb 2011 09:33:58 -0800
Cc: Stephen Zilles <szilles@adobe.com>, Håkon Wium Lie <howcome@opera.com>, "www-style@w3.org" <www-style@w3.org>
Message-Id: <C38882CD-4FDE-4A42-9AEB-41DFBB18EFD3@gmail.com>
To: Sylvain Galineau <sylvaing@microsoft.com>

On Feb 11, 2011, at 8:56 AM, Sylvain Galineau wrote:
> 
> Right. If can try to simplistically boil down the two approaches here, I think
> we have:
> 
> A. As CSS properties, column-* should follow the principle of least surprise.
> If the author specifies two properties and leaves the third auto then the
> first two shall be honored as best as they can e. The suitability of the outcome
> to the content being laid out is none of our business. 
> 
> B. Since multicol elements exist to address a scenario that single content 
> box elements cannot deal with, and since they flow their content in multiple
> boxes within the same element, they are far more sensitive to changes in available
> width and overconstrained cases. So much so we might want to consider extra 
> properties (min-column-*) and/or a default behavior that maximizes the combined 
> outcome of all column properties rather than simply obtaining individual computed 
> values equal or as close as possible to what the author specified.

Good breakdown.

> I fully agree that A. is the right starting point. I also think Hakon's proposal
> reinforces A e.g. minimizing abrupt changes in column count in order to remain as 
> close as possible to what the author specified. (What he refers to 'minimizing abrupt
> changes').

Yes. 

> But I also think B has merit for the primary use-case i.e. maximizing the amount
> of space available to lay out content is what I suspect you want for something
> like a NYT Reader or The Daily. If this primary use-case requires more work (be it
> specifying more properties or media queries) vs. that required for more exotic 
> use-cases then I wonder if we're letting A. get in the way. Is consistency as much
> of a benefit if it produces outcomes you don't want more often ?

My main concern is that approach "B" will limit what is possible with "A". If the unusual cases have to set one extra property instead of the common cases setting one extra property, then I am OK with that. 

If there was a 'min-column-width' that the UA style sheet set to 8em or whatever, well, I'd find that unexpected, but as long as I could override it (without using 4 different experimental syntaxes) then fine.

>> If we want min-column-width, then lets just have that property and let
>> authors set it. For that matter, a min-width on the multi-column element
>> would seem to work just as well.
> 
> Sure. Why not min-column-gap too ? If we're going to take the stance that 'we don't
> know what people will want to do with it' then shouldn't we let them set all the
> priorities ?

I think I have to reread your ideas about reducing the gap sizes a little more carefully. I'm not sure I am grokking all the details and implications. But I do feel that column-gap is a very close cousin to padding, and that's why min-column-gap doesn't feel quite right to me. It's like saying min-padding.
Received on Friday, 11 February 2011 17:34:34 GMT

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