RE: [css3-multicol] pseudo-algorithm

>From my perspective, this discussion is proceeding in a useful direction.

I acknowledge advocating a minimum width to columns, but I also believe that that width should be allowed to be overridden; that was my reason for arguing we should have a "minimum-column-width" property. After reading the recent exchanges, I also realized that rather than having a fixed default for the minimum-column-width, that minimum width should depend on the value of column-width. The minimum-column-width should be no larger than the column-width and should be equal to it when the column-width is less than the proposed fixed minimum-column-width. That is, the "default minimum-column-width" is only a suggestion that the author can override using the column-width property. With this additional proviso, the author could have columns as narrow as he wanted by specifying the column-width as narrow as he wanted. I believe that this kind of a "initial value" for minimum-column-width would in many cases remove the need for the author to explicitly specify minimum-column-width and still have reasonable behavior for "primary use-case"; namely, text. 

I agree that Model A, below, is the way to handle situations that are not over-constrained. I do understand that the "principle of least surprise" means that the UA should not willy-nilly adjust values. Too me, however, the reason a given feature was introduced, its "primary use-case", should have an important role in determining behavior in over-constrained cases. UA adjustments should be done in a way that makes sense for that primary use-case when the situation is over-constrained and it should take that use-case into account when deciding whether the situation is over-constrained. It is the latter point that caused me to suggest adding a minimum-column-width as another constraint to satisfy; that is, as a constraint that leads more quickly to an over-constrained situation.

I have suggested "minimum-column-width" and Sylvain has suggested "adjusting the column-gap" as ways to achieve a (to us) more reasonable behavior for the primary use case. There may be other ways to achieve the same goal. But, we will not make progress unless we agree on what goal we are trying to achieve. The goal I hope we are trying to achieve is "having a reasonable behavior for text in columns situated in a container whose size is decreasing."



Steve Zilles


> -----Original Message-----
> From: Brad Kemper [mailto:brad.kemper@gmail.com]
> Sent: Friday, February 11, 2011 9:34 AM
> To: Sylvain Galineau
> Cc: Stephen Zilles; Håkon Wium Lie; www-style@w3.org
> Subject: Re: [css3-multicol] pseudo-algorithm
> 
> 
> 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 Saturday, 12 February 2011 21:45:13 UTC