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

Re: [css3-multicol] Clarification on column-fill

From: Robert O'Callahan <robert@ocallahan.org>
Date: Tue, 1 Nov 2011 10:37:50 +1300
Message-ID: <CAOp6jLa+dORcvgVRR0+YYNtSvjF0WaV1Z1JLBTfuAZt1KGbYgA@mail.gmail.com>
To: Håkon Wium Lie <howcome@opera.com>
Cc: Scott Johnson <sjohnson@mozilla.com>, www-style@w3.org
On Mon, Oct 31, 2011 at 6:13 PM, Håkon Wium Lie <howcome@opera.com> wrote:

> Also sprach Robert O'Callahan:
> > The spec says "In continuous media, this property will only be consulted
> if
>  > the length of columns has been constrained. Otherwise, columns will
>  > automatically be balanced." Unfortunately "constrained" is completely
>  > undefined :-(.
> It's a term that we have a habit of using in CSS. I think you
> understand what is meant. Do you have suggestions for how to reword
> it? This would be an editorial comment, so it should be possible to add.

I actually don't know what it means.

Clearly an element whose computed height is non-auto is constrains the
length of its columns.

I assume an element whose computed max-height is not 'none' constrains the
length of its columns, but that's not 100% clear.

Is an element in a context which permits breaking in the block progression
direction considered to have a constraint on the length of its columns? I
honestly don't know.

What about an element with an ancestor whose computed height or max-height
is not auto/none? Probably doesn't constrain the lengths of columns in
descendant elements, but I'm not sure.

  > (Your use of the word "unbounded" is undefined too :-).) The
>  > phrase "continuous media" is also obsolete now that we can have columns
>  > flowing into arbitrary regions.
> I don't see how regions obsoletes the distinction between paged and
> continous media?

Is an element in a region with several pieces that act like pages, that's
in a galley presentation, considered to be in continuous media? Why should
it be treated differently to an element in paged media?

 > It also seems odd to have the fact that a
>  > page-break might exist far away from an element with columns affect the
>  > layout of those columns.
>  >
>  > I think it would be simpler to remove that paragraph and just make the
>  > property always apply. This means when the element's height is auto and
>  > max-height is none, and there's no pagination or region stuff happening,
>  > column-fill:auto will put all the content in the first column, but
> that's
>  > OK IMHO; 'auto' is not the default value, and authors should only use it
>  > where it makes sense.
> The last call would have been the time to raise this. The spec is now
> in CR, so non-editorial changes are expensive.
>  http://dev.w3.org/csswg/css3-multicol/last-call.html

Sorry. If we decide that's the right thing to do, we can always implement
the right thing and fix the spec later. I don't like W3C processes inducing
us to freeze on agreed-suboptimal behavior.

"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us." [1 John
Received on Monday, 31 October 2011 21:38:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:51 UTC