RE: [css3-multicol] pseudo-algorithm

[Brad Kemper:]
> On Feb 10, 2011, at 6:25 PM, Sylvain Galineau <>
> wrote:
> > You are entering this branch of the algorithm *because* you can't get
> > what you asked for. At this point, what is more important ? That the
> > browser mindlessly aims to get as many columns as possible, even if it
> > results in the vast majority of the multicol element being empty ?
> Yeah, actually, if that's how I authored the page.
> > Or should it try to honor both the number of columns you want and
> > respect your content - never mind the user's ability to consume it -
> > before it respects intra-column space ?
> It doesn't know nearly as much about my content and what I want to do with
> it and how to respect that, as I do. I dont see current browsers reducing
> my padding to make sure there is room for words in my paragraphs (thank
> the gods). I really don't see why margin gap should be any different.

Absolutely right. They don't do that. But does that prove it would not be an
attractive option in overconstrained cases ? In any case, nobody here is 
suggesting that you should not be able to specify such a result. The question 
is whether this behavior makes sense for the primary use-case of multicolumn 
elements, which is laying out columns of text. Another way to put it is that 
the primary use-case should result in less work vs. alternative use-cases.
I don't mind you having to do a little more work for your custom scenarios
than the guy who just wants to lay out text. 

Once content flows into multiple boxes inside one elements, I'm not sure applying 
the single content box model no matter what is inherently desirable or better.
If absolute consistency results in more work in the primary use-case - or, God 
forbid, media queries where none existed before - then maybe it *is* different.

Usability side note: if it were called column-padding then I'd agree it shouldn't
violate author expectations.

> > There are many good reasons why the author may want to use media
> > queries. But he shouldn't have to because multicol fallback in
> > overconstrainted cases looks horrible by design.
> I'd rather have the power to make those sort of design decisions on my own
> for the pages I author and style. I don't want the UA to decide if my
> design is too horrible or good enough without knowing anything about WHY I
> chose to have lots of wide column gaps in a narrow space.

Nobody said you shouldn't be able to. Nobody said the UA should make design
decisions either. What is discussed is the *default* behavior and the impact
of *one* proposed change on the feature's primary use-case. Asserting this 
behavior is self-evidently better for undefined hypotheticals by virtue of 
being consistent with element types that cannot address the feature's primary
 use-case is not really helpful here imo. 

Received on Friday, 11 February 2011 15:46:35 UTC