W3C home > Mailing lists > Public > www-style@w3.org > August 2003

CSS3 multi-column layout

From: Bryan C. Mills <bmills@andrew.cmu.edu>
Date: Mon, 11 Aug 2003 13:50:24 -0400 (EDT)
Message-ID: <Pine.LNX.4.55L-032.0308111102580.4552@unix48.andrew.cmu.edu>
To: www-style@w3.org



I am a Programming Languages student at Carnegie Mellon University and
part-time web developer.

I was looking at the CSS3 working draft today, in particular at the
proposal for multi-column layout.

It seems like a good design, but I have additional suggestions which
I think would help reflect common use of columnar formatting;
specifically, user control of flow.

First, it should be more strongly emphasized that 'width' properties of
child elements refer to the width of the column, not the width of the
columnar layout.  Confusion about 'width' is the source of a current
Internet Explorer CSS bug which severely cripples layout in data next to
floating elements.
'column-width' should be specifiable on a column-by-column basis, so that,
for example, one might use 'column-width: 25% 75%' to split a block into a
1/4, 3/4 layout.

Second, it should be made explicit in the standard that block content is
not to be broken across columns, or there should be a property which
specifies how columns are to be broken within child elements, as follows:

============== Child column breaks ==================

9.3 'column-spread'
Value: auto | <integer>
Applies to: inline-level elements
Inherited: no
Percentage values: N/A

   The 'column-break-inside' property specifies how a user agent should
split content of an element between multiple columns.  To
maintain  consistency with the box model, this property can only be set
for inline-level elements (block-level elements must have value 1).
   The value 'auto' specifies that the user agent may break the element
into columns arbitrarily, according to normal column flow.
   An integer value specifies the number of columns this element should
flow into.  If 'column-count' is not 'auto' and this value would cause
the total number of columns to exceed the value specified by
'column-count', the user agent should ignore this value.
   The user agent should attempt to split the columns evenly, but is not
required to do so except as required by normal flow of the rest of the
content.  A user agent is, however, required to generate only non-empty
columns if possible.
   It is anticipated that the most frequent usage of 'column-spread' will
be to prevent column breaks in a set of inline data, although it is
designed to be more generally applicable.

================== End Child Column Breaks =====================


With the CSS "float" property, there is the matching "clear" property
to specify where content should break around floating elements.
I think there should be an additional facility in CSS3 to control column
breaks.
I would suggest the following additional property:

================ Between-element column breaks ===============

9.2.1 'column-break'
Value: auto | before | after | both
Applies to: all elements
Inherited: no
Percentage values: N/A

  The 'column-break-before' property specifies column behavior directly
before an element.
  A value of 'before' forces the user agent to make this element the first
in its column, if possible.  Likewise, a value of 'after' forces the
user agent to make this element the last in its column, if possible.
  If 'column-count' is not 'auto' and a column break would force the
number of rendered columns to exceed the value specified by
'column-count', the user agent should first remove any column
breaks not explicitly required.  If the number of explicit column breaks
still forces the number of columns to exceed the number specified by
'column-count', the user agent should enforce the 'column-count' value,
ignoring only enough explicit breaks to do so.
  A value of 'column-break' should not cause a user agent
to render an empty column, even when such a break is called for at the
beginning or end of a multi-column layout, or when an element with
'column-break: after' precedes an element with 'column-break-before'.

=============== End between-element column breaks ==================

Finally, I believe that the current working draft for floating in and
between columns is insufficiently explicit to be useful for content
development.  Conforming implementations will not necessarily produce
similar results, and the columnar float standard as specified in the
working draft is incompatible with the current rules governing floats.

I suggest that 'in-column' be replaced with the more generic 'below',
defined as follows:

'below' places the content with its right margin edge aligned as close
as possible to the right margin edge of the preceding element and on the
line below.  Text then flows around it, starting at the right
margin edge of of the preceding element (above the floated element).

'below' combined with 'width: 100%' would be equivalent to the working
draft's 'in-column' for floating elements not at the top of the column.

A simple 'width: 100%' with the proposed 'column-break: before' would be a
suitable alternative for floating elements at the top of the column, and
would present less of a risk to the 'float' standard and implementation.

'mid-column' should be replaced with 'mid-column-left' and
'mid-column-right', as follows:
'mid-column-left' should float the content on top of the column rule to
the left of the current column; if no such column rule exists, this value
is equivalent to 'left'.
'mid-column-right' should float the content on top of the column rule to
the right of the current column; if no such column rule exists, this value
is equivalent to 'right'.

User-agents should NOT be free to place floating images vertically in
columnar elements, but rather should be restrained by the rules governing
behavior of floats.  This is important for consistincy and ease of
implementation.

Thank you for taking the time to consider my suggestions; if you have any
questions or comments a reply would be most welcome.

Sincerely,

Bryan Mills
Received on Tuesday, 12 August 2003 05:21:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:23 GMT