RE: [css3-multicol] pseudo-algorithm

[Brad Kemper:] 
> Maybe I misunderstood then. I thought Stephen and maybe others were saying
> that columns should have a minimum width that I would not be able to
> override until possible some future version of the spec added that
> capability (CSS4 Columns?). That would seem to make it impossible to have
> a truly flexible-width column (down to 0 pixels) with a fixed-width gap
> and fixed number of columns.

Well, it's entirely possible that I'm misunderstanding everyone else. Maybe
I should be careful about claiming 'no one' implied something and speak for 
myself :) I think this was indeed suggested but as a way to resolve a particular
issue. I didn't read it as excluding the ability to do other things. 

> My gut tells me that there are all kinds of useful but unforeseen things
> authors could do with that if it was possible, and it would certainly be
> less surprising than running into a hidden UA constraint. The edge cases
> of actual text going into columns that end up in that sort of over-
> constrained situation, where the author allowed many columns in a narrow
> space but didn't put in anything to deal with it, seems less likely.
> Writing a one or two line media query to reduce the number of columns does
> not seem at all onerous when dealing with all the other issues of
> extremely flexible (in terms of min-width) layouts.

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.

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

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 ?


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

Received on Friday, 11 February 2011 16:56:39 UTC