Re: [css3-multicol] overflow and paging?

Tad Akins is correct that the current spec is not ambiguious when __BOTH__
the block and inline directions are constrained. The spec does have a
logical error (or possible misinterpretation) with respect to this, and
IMO is also a bit less than optimally coherent in Section 8.2. I will
suggest improved wording, as well summarize all the discussion and
findings so far in this thread, explain why IMO we need to reach concensus
on the proposed improvement asap.

I finally got enough sleep and time to spend on this to hopefully make it
more coherent. I apologize if my tone came across as abrasive when I was
trying to hastily report this issue (was a inopportune distraction from
some unrelated work I was several days beyond sleeplessly rushing to
complete). Not an excuse, I mean an apology.

We must take action to more coherently specify how browsers should layout
multi-columns when __BOTH__ the block and inline directions are
constrained, and to provide a setting for the direction of the overflow,
when the overflow is not due to a page border. Without this new setting,
the browsers are apparently violating the spec, obstensibly via a
hueristic to give users a way to achieve both choices of the non-existent
setting, as I will explain below.

I had a slight mistake in specifying my case in my prior emails on this
thread, where I forgot to mention that the constraints are in the parent
of the multi-column container element.  A corrected example of my case is:

<div style='width:250px; height:600px; overflow:auto'>
   <div style='-moz-column-width:125px; -webkit-column-width:125px;
column-width:125px; -moz-column-gap:3px; -webkit-column-gap:3px;
column-gap:3px'>
      ...same example content as I reported before
   </div>
</div>

In the above example, and if the block direction is vertical, currently
the browsers I have tested (IE6, FF3.5.x/3.6.x, latest Chrome) are not
adding any columns in either direction, but rather allowing the column
height to exceed the constrained height (as inherited from the element
which is the parent of the multi-column container) in violation of Section
8.2, thus causing a vertical scroll bar to appear on that parent element.
This was shown in my prior diagrams:

http://lists.w3.org/Archives/Public/www-style/2010Oct/0166.html

As suggested in prior comments in this thread, when __BOTH__ inlie and
block directions are constrained, the desired behavior is that the column
height should be limited to the constrained height (block direction
constraint) per Section 8.2, and the proposal for a choice whether
additional columns should either be added in the inline direction or
additional column rows should be added in the block direction. Tad Akins
has proposed the setting for this choice, "column-overflow:inline|block",
which I have agreed with. I noted that this setting will be ignored when
__BOTH__ directions are not constrained, because then there is no
overflow, as the container element is expanded in the unconstrained
direction.

Note Tad Akins reported that if "overflow:inherit" (no overflow setting)
and if __BOTH__ constraints are on the multi-column container (rather than
on the parent of that container), then the current browsers he tested are
adding columns in the inline direction and thus are compliant with Section
8.2.

We get two different results even though his test and my test have
__BOTH__ the block and inline directions constrained (e.g. height and
width both specified on the container element or its parent element).

Section 3 specifically states it applies only when the block direction is
unconstrained.

IMO, section 8.2 is not optimally succinct and coherent. Let me translate
it. Section 8.2 means that the column height must never exceed the block
direction constraint, if it exists. Section 8.2 also means that when the
block direction constraint is not due to a page border, then the columns
should overflow in the inline direction. The current spec could be
misinterpreted because paged media may also contain instances of block
direction constraints which are not due to a page border and such cases
should be treated the same as the spec says for continuous media, and thus
my specification above is more correct (and IMO more succinct and
coherent).

Now given that the spec current means (intends) for overflow to always
spill in the inline direction, unless due to page border, then this thread
is proposing to add the "column-overflow:inline|block" setting to let the
user control the overflow direction, when not due to a page border. It is
an important proposal, because otherwise there is no way to __SCROLL__
multi-columns within a container element in the block (vertical)
direction. The only reason I am able to achieve it in my example, is
apparently because the browsers ignored the spec. The browsers are
probably ignoring the spec, because there has to be some way to get a
vertical scroll. The spec is lacking the appropriate setting, so the
browsers probably just use the hueristic of when the constraints are only
explicitly on the parent element, then overflow direction on the child
multi-column container (which inherits the constraints) is in block
direction.

Unfortunately the browser's hueristic enabled the vertical scroll, but
didn't limit the column height to the block constraint (i.e. element
height), as I showed in my prior emails and diagrams in this thread. The
column height must never exceed the block direction constraint per Section
8.2, and the only variable can be which direction (inline or block) to
flow the additional columns.

I hope we can agree on this asap?  Vertical scrolling on overflowed
multi-columns is needed (and thus is being used in the market with a
hueristic deviation from the spec) and having the browsers doing it
heuristically is not good.

If there are any mistakes in this email, please let me know. Otherwise can
we move towards concensus on this?


Section 2
===================

http://www.w3.org/TR/css3-multicol/#the-multi-column-model

"Column boxes in a multi-column element are arranged into rows. Like table
cells, the column boxes in a row are ordered in the inline direction of
the multicol element."

"The column height is the length of the column box in the block direction.
All column boxes in a multi-column element have the same column width, and
all column boxes in a row have the same column height."

"In the simplest case a multicol element will contain only one row of
columns, and the height of each column will be equivalent to the used
height of the multi-column element's content box."



Section 3
===================

http://www.w3.org/TR/css3-multicol/#the-number-and-width-of-columns

"When the block direction is unconstrained and no column breaks are added
through style sheets, these two properties determine the outcome:

    * ‘column-count’
    * ‘column-width’"

So obviously section 3 does not apply when the block direction is vertical
and there exists a height specified for the container element. Thus lines
of pseudo=algorithm in Section 3.4 do not apply:

http://www.w3.org/TR/css3-multicol/#pseudo-algorithm

"(27)  elsif (column-count = auto) then
(28)    if (column-width >= available-width) then
(29)      N := 1
(30)      W := available-width;
(31)    else
(32)      N := floor((available-width + column-gap) / (column-width +
column-gap));
(33)      W := ((available-width + column-gap) / N) - column-gap;"



Section 8.2
===================

http://www.w3.org/TR/css3-multicol/#overflow-outside-multicol-elements

"Content that extend outside column boxes at the edges of the multi-column
element is clipped according to the ‘overflow’ property.

A multicol element can have more columns than it has room for due to:

    * Constrained column height. A declaration that constrains the column
height (e.g., using ‘height’) must be honored, if possible. In paged
media, the column height is constrained by the size of the page.
    * Explicit column breaks. Explicit column breaks may create more
columns than there is room for inside the multicol element.

In continuous media, columns that do not fit within the multicol element
are added in the inline direction."

Received on Thursday, 14 October 2010 14:23:28 UTC