Re: New draft: multi-column

Also sprach Clover Andrew:

 > > A new draft of the CSS3 module "multi-column layout" has been
 > > published.
 > 
 > I find myself somewhat concerned by this spec. Okay, it's only a
 > draft, so many details are missing, but some of the *implied*
 > changes to layout algorithms seem to make things very tricky
 > indeed.

First, thanks for your comments. Your message is a good example of why
W3C should publish WDs publically, and it will surely influence the
next version of the document. My comments follow below. 

 > A change in flow from one column to the next can seemingly occur
 > in the middle of inline content. Meaning a block is no longer a
 > rectangle; it can span any arbitrary collection of rectangles.

True, but this is also the case today: an inline element can span
several lines and thereby generate more than one "rectangle". UAs that
support paged layouts (e.g. printing) must also be able to break
inline elements over several pages.

 > This has implications for border, margin, background alignment
 > and so on that should be specified. It makes positioning and
 > scripting difficult - how can you read/set the position and
 > size of a rectangle that's split over three columns, for example?

Indeed, this is difficult for inline elments and that's why 'width'
and 'height' do not apply to inline elements. Positioning is possible,
however, see below. 

 > It seems to me that multi-column layouts are most useful for
 > print media rather than a scrolling viewport. 

In general, yes. 

 > But how do
 > multi-column layouts work over page breaks? Does the break
 > force column balancing? 

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

Could you elaborate your question?

 > Do we need column-break-*
 > properties?

I hope not. Use tables if you know where the breaks should go.

 > Can you put a multi-column layout inside another
 > multi-column layout? 

I don't see why not -- just like tables can be inside tables. Or, do
we run into impossible situations?

 > Could multi-page layouts be considered
 > a special case of multi-column layout?

Interesting idea. In which case, common browsers already support
multi-colum layouts...

 > The multi-column spec as outlined here looks nice and simple,
 > but what happens when it's combined with positioning? Bi-di?
 > Ruby? 

I don't see how these problems differ from those arising in today's
layouts. An absolutely positioned element will be taken out of the
flow and positioned relative to its containing block. A relatively
positioned element will be positioned relative to where it normally
would end up. Etc.

 > mid-column floats are nice, but what happens when
 > there's not enough space for them? When they get in the way
 > of a standard floating element? 

I agree there are issues here that need to discussed. The general
principle should be that floating elements push aside other content
and that content extend outside the content box when there is no other
alternative.

 > Column-span is handy, but
 > it seems to also affect how many columns the *previous*,
 > not-spanned elements take up.

How so?

 > Can a "column-span: 2" element
 > also run through a second double-width column, filling
 > four columns in all?
 > 
 > I'm sure there's many more subtleties I haven't yet seen,
 > but already this is making the task of layout extremely
 > complex, for a feature I personally believe is of limited
 > usefulness on the web. Multi-column layouts are great for
 > paper, but in a window that you have to scroll down to
 > read, they're only practical for relatively small amounts
 > of text, otherwise you'd have to keep scrolling down and
 > up again to get through it.

Don't equate the web with scrolling windows. Printers, projectors, TVs
and internet appliances of all kinds must also be included.

CSS can describe common typography, but without multi-columns one will
not be able to print decently from the Web. Also, headers and footers
must be supported.

  http://www.w3.org/TR/css3-page

 > Sorry if this sounds overly critical; these are just the
 > objections that came to mind whilst reading the spec. There
 > are, OTOH, many things I *do* like in the spec, like the way
 > the number of columns isn't (as I had feared) fixed. 

Yeah, that's my favorite, too!

-h&kon
              Håkon Wium Lie                            ¢tº €þe®ª
howcome@opera.com               http://www.opera.com/people/howcome

Received on Monday, 22 January 2001 11:36:36 UTC