W3C home > Mailing lists > Public > www-style@w3.org > January 2001

Re: New draft: multi-column

From: Clover Andrew <aclover@1value.com>
Date: Tue, 23 Jan 2001 18:29:27 +0100
Message-ID: <D58B0195B58937489E89124469E57CA20D4F63@EX1.1value.com>
To: <www-style@w3.org>
With maximum available gravitas, Håkon Wium Lie intoned:

> First, thanks for your comments.

Thanks for listening! It's great that W3 development is open to
public interaction.

I'm going to repsond to Bert's comments here too, since he also
contributed to the WD. >> is me, the other quotes are modal. :-)

My viewpoint is that of a potential browser author, which is
why complexity concerns me; I've always wanted to write a
svelte UA (yes, smaller even than Opera!), particularly for
minority platforms, and though I'll almost certainly never
get the time for such an ambitious project, I like knowing
that I *could*. Developments like multi-column give me the
horrible feeling that Things Just Got An Order Of Magnitude
Harder, something I last remember feeling about CSS-P.

>> Does the break force column balancing? 
Lie> It should.
Bos> I don't know if it is necessary to balance columns on each page.

>> Do the page-break-* properties of children work relative to the page?

Lie> Could you elaborate your question?

>> Do we need column-break-* properties?
> I hope not. Use tables if you know where the breaks should go.

I found the difference between 'auto' and 'avoid' useful, though.
Still, there's the possibility you might want to skip to the next column
without fixing *all* the column break points... one could do it with
a multicol inside a table cell I suppose, but - oh no! - it's using
tables for layout.

('left' and 'right' don't make any sense for columns, obv. Unless
odd-numbered columns are arbitrarily 'right'.)

Come to think of it, I believe the above three quoted questions run
together. There are two consistent alternatives I can think of.
This is how I'd illustrate them, where | is a column break, and
-- is a page break (although it could equally be a higher-level
column break, if nested multicols are allowed).

  1.                             2.

  abc def  |  mno pqr            abc def  |  yza bcd
  ghi jkl  |  stu vwx            ghi jkl  |  efg hij
  ---------+---------            ---------+---------
  yza bcd  |  klm nop            mno pqr  |  klm nop
  efg hij  |  qrs.               stu vwx  |  qrs.

1. Page breaks and column breaks enforce column balancing down all
   their children (where multi-columns are inside other multi-columns),
   so a page break always enforces a column break, which always
   enforces column breaks in child multi-column elements.

   'column-break-*: avoid' avoids making a column break in the
   innermost multicol, and hence also avoids higher-level column
   breaks and page breaks. 'column-break-[before|after]: always'
   breaks the innermost column, and may also break higher columns if
   they're full.

   1a. 'page-break-*: always' breaks not only the column, but
       everything up to the page. 'page-break-*: avoid' allows
       column breaks as long as they don't mean going on to the
       next page.

   1b. There is no 'column-break-*'. You just use 'page-break-*' and
       it means the innermost multi-column element, not the page.

   1c. 'page-break-*' is disallowed, or doesn't do anything.

   1d. Neither 'column-break-*' nor 'page-break-*' have meaning.

   (As Bert mentioned, where there are column breaks, I guess
   widow-orphan-control should happen.)

2. Page breaks and column breaks due not enforce balancing inwards.
   The content of a multicol is exactly as if its content was rendered
   in a single block of the appropriate width, then cut into the
   appropriate number of columns and put side by side. (Floats

   2a. 'page-break-*: avoid' still tries to avoid splitting over a
       page boundary, but doesn't care about splitting over columns.
       'page-break-*: always' inserts enough space inside the
       the column to continue writing text on the next page, but
       in the same column, so the entire multicol takes up more than
       one page.
   2b. 'page-break-*' means the innermost column break.
   2c. 'column-break-*' means the innermost column break, and
       'page-break-*' means the page break. Both properties are
       totally independent since one can have a page break without
       a column break and vice-versa.
   2d. 'page-break-*' is disallowed or doesn't do anything in
       multicols. There is no 'column-break-*' either.

My own favoured option would probably be 1b.

Bos> A positioned element can clearly contain columns.

Yes. The question is, can columns contain positioned elements?

Lie> A relatively positioned element will be positioned relative to
> where it normally would end up. Etc.

So, is a relatively positioned element in a multi-column-element
split into however many pieces and *then* each one moved by the
given left/top properties? This would imply:

  <div style="column-count: 2">
      abc def ghi
    <p style="position: relative; left: 1em; top: 1em">
      jkl mno pqr
      stu vwx yza
      bcd efg.

could end up looking like:

  abc def ghi
                 stu vwx yza
               bcd efg.
    jkl mno pqr

which is guess is okay...

> An absolutely positioned element will be taken out of the
> flow and positioned relative to its containing block.

But what if the containing block is split between columns?
Taking the previous example, what happens if we add an
absolutely-positioned element inside the relatively-positioned

  <div style="position: relative; left: 1em; top: 1em">
    <p style="position: absolute; left: 0; top: 1em">
      123 456 789
      012 345.
      jkl mno pqr
      stu vwx yza

Possibilities I can see:

1. Absolute positioning has a higher priority than multicolumn.
   The absolute child 'escapes' its column-split relative parent
   and hangs independently outside of the multicol. Result:

  abc def ghi
                 stu vwx yza
               bcd efg.
    jkl mno pqr
    123 456 789
    012 345.

2. Column breaks have a higher priority than absolute
   positioning. The absolute child is rendered inside the
   relative parent, and then split. Result:

  abc def ghi
                 123 456 789
    jkl mno pqr

I like option 2 because it's similar to how page breaks are
currently handled. However it means that each positioned
element must establish not only a new co-ordinate origin
for child elements (like it does now), but an entire new
co-ordinate context, which will get split up into
columns later. So moving an element downwards in the style
definition could have the effect of moving it rightwards
(into the next column) on-screen.

Which is fun!

>> Column-span [...] seems to also affect how many columns
>> the *previous*, not-spanned elements take up.

> How so?

In the example given in the WD, the <h2> spanning two
columns make the previous <p> fill two columns. "A value
other than 'none' will enforce column balancing." - but
only of the columns 1..value, leaving further-right
columns to receive more content. The number of columns
an element with 'column-span: none' is split into
is the number specified for column-span in the *next*
element that doesn't have 'column-span: none', or all
remaining columns if there isn't a spanned element
before the end of the multicol.

I'm not saying this is inconsistent, it just didn't seem
very intuitive at first.

What happens if the last element inside a multicol is
spanned, but not spanned across all cells? In the WD example,
if one took away the final <p>, which contains 3, 4 and 5,
would the column where 5 currently is become empty?

Bos> I don't know what you mean by a "double-width column."

I had wondered whether a element spanned across n columns
could include a column break and flow into the next n columns
to the right.

I now *suppose* only non-spanned elements can break, though,
which is the difference between column-span '1' and 'none'.
Is this correct?

Lie> CSS can describe common typography, but without multi-
> columns one will not be able to print decently from the Web.

True. Do you foresee, eg. 'body {column-width: 8cm}' being a
normal declaration for a default print-media user stylesheet?
Or should authors take responsibility exclusively?

Bos> (Which doesn't seem to keep some designers from using columns
> on screen anyway...)

Indeed. Maybe this spec should be kept secret to avoid abuse
from the Children of Siegel!

> Bi-directionality works, I expect, like for tables: if the
> element has a 'direction' of 'rtl', then the columns grow from
> right to left.

Okay... so the direction of the element with the multi-column
properties dictates the layout of the columns and the spanned
elements (which bind to the right for 'rtl'). That makes sense.

Not sure what'd happen with ruby; columns don't make much
sense for a vertical-reading language... unless they turn into
rows... ugh, no, forget I said that.

I'm going to leave the discussion of floats for the moment,
because the WD is deliberately vague on layout algorithms for
them. On a related note, I take it that floats float over
a multicol's content like any other div, that is:

  abc  jkl FLOAT
  def  mno  stu 
  ghi  pqr  vwx

so only the content in columns obscured by the float is
affected, not the size of the multicol itself. Is this

Incidentally, the link to the multi-column spec on the Developing
CSS3 page at w3 is a bit of-of-date; it links to the June 1999
draft. I notice the issue of setting properties on the columns,
dealt with in the older draft in 'variation 1' and 'variation 2',
has been left out of the current WD ('may be defined in the
future'). May I suggest another variation?

What about if the margin, padding and background of the element
with the multi-column properties applied to each column
separately, rather than the box containing them all? You'd
get the advantages of 'variation 2' (no need to define
special properties for gaps and rules) without the disadvantages
listed there. You'd lose the ability to set margin etc. for
the implicit containing box, but in practical terms that's
easily gained by wrapping another <div> around the multicol.
Was this one of the solutions already considered and rejected?
If so, why?

Finally, has anyone considered the impact of multi-column
layouts on progressive rendering? I personally can't think of
an a way of rendering until the entire content of the multicol
is available - is there a good approach to take to this problem,
short of a constantly-resizing layout?

Oh dear, I seem to have composed an epic. Enough already.


Andrew Clover
Technical Consultant
Received on Tuesday, 23 January 2001 12:36:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:56 UTC