Re: [css3-multicol] overflow and paging?

> On Tue, Oct 12, 2010 at 3:53 AM, Shelby Moore <shelby@coolpage.com> wrote:
>>> http://www.quirksmode.org/css/multicolumn.html
>>>
>>> I haven't seen that behavior in my site using column-width.  Is it
>>> because
>>> I am setting both the width and the height of the container? Or is
>>> because
>>> I have overflow:auto?
>>>
>>> I really don't like undocumented behavior. Can someone from Mozilla
>>> explain?
>>
>> Okay you were obviously describing case "Test 6" at the above link,
>> which
>> I missed.
>>
>> Here is the relevant part of the spec:
>>
>> http://www.w3.org/TR/css3-multicol/#overflow-outside-multicol-elements
>>
>> That part of the spec exacts says to do what I have posited in this
>> thread. Apparently the browsers have mis-interpreted that part of the
>> spec. Let me explain.
>>
>> That part of the spec says that when the height is specified, then
>> "column
>> height" must not exceed that height. But go back to the definition of
>> "column height", it does not mean that additional columns can not be
>> flowed below, rather is only means the maximum height of the columns per
>> row of columns.
>>
>> Thus the browsers have implemented this wrong.  They are supposed to be
>> doing what I showed in the diagram of my prior comment in this thread,
>> which is that when both the width and height of the container are set,
>> the
>> layout must create rows of columns overflowing vertically with maximum
>> column height equal to the container's height (minus padding). They are
>> overlowing vertically, but they are not setting the column height per
>> the
>> spec.
>>
>> Whereas, when the height is set and not the width, then they are free to
>> create more horizontal columns (to fill up the available width of the
>> parent of the container), disrepecting any column-count setting. This is
>> what David Storey is writing about, and this behavior agrees with the
>> spec. If you don't want that behavior David, simply set the width on the
>> container element.
>>
>> If we can agree, I will go post bug reports for Mozilla and Chromium?  I
>> will let you others post bug reports at the other browsers.
>
> No, this is incorrect.  The spec is fairly clear about how this is
> supposed to act.  There are a number of scenarios, based on what
> constraints exist.  None of them involve doing page-like overflow.


Apparently that is correct, the spec does not currently appear to require
pagination for any overflow case.


>  If
> the height is constrained, then overflow always results in generating
> new columns in the "after" direction.  From the spec, section 8.2: "A
> declaration that constrains the column height (e.g., using ?height?)
> must be honored, if possible. ... In continuous media, columns that do
> not fit within the multicol element are added in the inline
> direction."


But the spec is apparently ambiguous as to what to do when the _BOTH_ the
height and width are constrained.

As per my tests in all browsers (IE6, FF3.5.x, FF3.6.0, latest Chrome),
when column-width, width, and height are all set, then the overflow:auto
flows out the bottom, i.e. no extra columns are created.

But alas, without any pagination, so thus is not ideal. Given that the
spec is ambiguous on the case of simultaneous height and width constraint,
I suppose we are free to specify now what should be done?  Normally we
would adopt what all the browsers are already doing? Thus we would have to
add a non-default setting for column-overflow:paginate?  But that is a
shame, as I think the default should be to paginate.


> If height is unconstrained, then overflow columns are never created
> (unless column breaks force them), because you can just grow the
> height of the element to fit the rest of the content.

Agreed.

> This is the
> situation you're running into.

No my situation is to constrain both the height and the width.


> To accomplish what you want, which I agree is valuable,

Thanks happy to hear that. Any others agree?

> will indeed
> require a new mode-switch, something like "column-overflow: inline |
> block" to specify where overflow columns get created.

Okay, so if block is in the same direction as column rows, then it means
there must be pagination, because maximum column height has to be
respected from section 8.2: "A declaration that constrains the column
height"?

So thus block is equivalent result in to my suggestion
column-overflow:paginate? (I like it, more orthogonal then my paginate
suggestion)


>  It will also
> require a way for you to specify the height of the container.


The height of the container is specified, otherwise there wouldn't have
been overflow.

Because that overflow direction is implied from the height and width
constraints, the only time the overflow direction is ambiguous is when
_BOTH_ height and width are constrained, which is resolved with your
proposed "column-overflow: inline | block".  Thus the "column-overflow:
inline | block" should be ignored unless _BOTH_ height and width are
constrained??


>  This is
> currently difficult for you due to the flexibility/unpredictability of
> your layout, but several of the new layout specs will make this easy
> to do.

OFF TOPIC: it is not too difficult, I am already setting the height.  It
is well tested.  I admit the browsers have bugs with respect to viewport
size sans scroll bars (I have to call things multiple times to get browser
to converge on stable value), but I think I have worked around most them
in JavaScript. It will be nice to have better layout features in future.

But in any case, that is only because I am setting the height to reach the
bottom of the viewport.  Other uses for which the proposed column-overflow
setting could apply, may set the container element height to some static
value. So that is why I label this part of as off topic. No offense
intended.

Received on Tuesday, 12 October 2010 18:25:30 UTC