Blogging and All that Malarkey Stuff & Nonsense

Malarkey is Andy Clarke, a creative designer with a passion for accessibility and web standards. This is his personal website.

CSS3 Multi-Column Thriller

As with all good thrillers, I want to find out what will happen at the end.

Mickey Spillane, Frank Miller, Hakon Wium Lie: Three of my favourite thriller writers. No really, because alongside Spillane's 'My Gun Is Quick' and Miller's 'The Hard Goodbye', another thriller hit the book stores web just in time for Christmas; Lie's CSS3 module: Multi-column layout. W3C Working Draft 15 December 2005.

Actually I would imagine that most people (who don't dissolve on contact with daylight) find W3C documentation rarely very thrilling. I must confess that personally I read it with all the enthusiasm of a man watching concrete being poured into his boots, and it's even rarer that I understand more than 50% of it anyway. But as someone who tries to keep <div>s and <span>s to a minimum, I am very interested in the (as yet largely unimplemented) potential of that snappily titled CSS3 module: Multi-column layout. W3C Working Draft 15 December 2005, the ability for content to flow from one column to another and how the number of columns can vary within liquid layouts.

Plus, as with all good thrillers, I want to find out what will happen at the end.

Mozilla 1.8+ and Firefox 1.5+

Back in September 2005, that mysterious Frenchman Cedric Savarese introduced the CSS3 Multi-Column Module at A List Apart and PPK and Eric have also discussed the latest Firefox release's support for a subset of these (multi-column) properties*. Now there's a new draft and unfortunately it's still only Moz/FF which currently supports any part of CSS3 columns.

Columns

There are two ways to implement multiple columns within an element (<body>, <div>, <p> etc.): the first by dictating the quantity of columns you require (column widths are automatically calculated), the second by dictating the width of columns (column quantities are automatically calculated to fill the available space).

body { column-count : 2 }
/* Column widths are automatically calculated  */
body { column-width : 15em }
/* Column quantities are automatically calculated  */

body { column-count : 2 }

body { column-width : 15em }

What's interesting is the ability for content to flow from column to column and for new columns to be created as the browser window expands, fantastic stuff. But from both design and readibility perspectives the results of this re-flowing can be very unsatisfactory, often resulting in content which becomes separated from its headers or images which become separated from their descriptions or associated text.

Ooops!

Fortunately there are a group of properties which determine where column breaks occur (for example above every <h3>),

h1 { column-break-before : always }
h2 { column-break-after : avoid }
h1, h2 { column-break-inside : avoid

but these themselves could have unforseen design issues including the introduction of large amounts of additional white-space or uneven column lengths.

h2 { column-break-before : always } Ooops!

Gutters, gaps and rules

To increase readibility and 'balance', two new properties have been introduced, column-gaps and column-rules. According to the Working Draft,

Column gaps and rules are placed between columns of the same element. The length of the column gaps and column rules is equal to the length of the columns. The column rule is placed in the middle of the column gap. Column rules do not take up space. That is, the presence or thickness of a column rule will not alter the placement of columns or column gaps.

body { column-gap : 1em; }

body { column-gap : 1em; }

body { column-rule : thin solid black; }

body { column-rule : thin solid black; }

Unfortunately, the current Working Draft allows for only basic styling of column-rule including 'dotted' and 'dashed' styles, plus the unusably ugly 'ridge' and 'groove'. Hardly a thriller. Nowhere does it seem planned to implement what I imagine many designers would like to use, image rules. I can think of many instances where images would be the perfect choice for column-rules.

I think that the following (familiar) syntax might be appropriate.

body { column-rule-image : url(rule.png); }

Even better would be the possibility of positioning those images as we can now do with background-image in CSS2.1 to allow us to position our rule images either at the top, bottom or vertical center of the column-gap.

body { column-rule-image : url(rule.png) repeat-x 0 0; }

Breakout!

Back in the W3C Working Draft 22 June 1999 (Ed says: Good heavens Malarkey, have you been to geek school?), there was a property which seems to have vanished to the bottom of the river in a concrete overcoat. That sad property was the column-span.

This enabled elements (for example <hx>s) to span a designated number of columns to create the effects we commonly see in newpapers. I can see how difficult that might be to implement and control, but the latest draft is severely lacking in a way to 'stop' and 'restart' columns with elements such as <hx>s and <div>s. I'll show you what I mean.

Perhaps something like this could help achieve that effect?

div.col_break { column-stop : before;  column-start : after; }

Pedal to the metal

I'm definately thrilled by certain aspects of CSS3 columns, but underwhelmed by others. I also don't think that the current Working Draft goes anywhere near far enough to meet the needs of modern designers. If CSS3 is going to be the revolution that I hope it will be then I believe that designers need to speak out and become involved in creating the specs. At the same time I hope that those at the W3C will actively solicit the help of creative designers to help them understand what we need now and into the future.

I also hope that those who are involved in creating specs such as this should recognise that a little haste would be nice. The CSS3 spec has been proposed since June 1999 and little has made it into the real world save for the efforts of those forward thinking people on the Apple Safari and Mozilla teams. With Firefox raising the bar, Microsoft working hard to improve Internet Explorer and thousands of developers worldwide using CSS every day, isn't it about time the W3C took off its cardigan of academia and joined in the Web2.0 buzz?

I'm sure that CSS3, including the CSS3 module: Multi-column layout will have a happy ending. I'm just not certain we can wait that long to find out.

Thoughts?

Replies

  1. #1 On December 30, 2005 10:57 PM Dave Simon said:

    Would be nice to get the word out to the IE7 folks too.

    This would be a really nice thing for all browsers to support.

    But I wonder how you could get designs using this to degrade gracefully in the current generation of browsers.

  2. #2 On December 30, 2005 10:58 PM Jeremy Freeman said:

    So you've spent your Xmas break reading the W3C documentation. You're a brave man!

    I wish you could revamp the W3C web site itself - it's enough to send anyone to sleep and turn people off accessibility.

    Rather you than me! Anyway, this was a thriller! ;)

  3. #3 On December 30, 2005 11:22 PM luxuryluke said:

    I love it, but have yet to see wide support for CSS3 items in browsers... perhaps once there is, I'll pursue this more. ...but I can't wait!!!

    @Dave Simon: As long as it's applied with a javascript behavior using DOM, perhaps it will degrade gracefully, not that I'm the one who knows how to do it (egad!).

  4. #4 On December 30, 2005 11:25 PM luxuryluke said:

    btw, one of the biggest pro's and cons for the column is that it will show all content in the viewable window without (necessarily) a need for scrolling. Defining the height of the columns will need to be determined based on the amount of the page that's actually viewable for most browsers...

    (right?)

  5. #5 On December 31, 2005 12:22 AM Rimantas said:

    On the other hand, if height is not enough for columns to fit we are in BIG trouble.
    I do not see myself using CSS columns for regular text - single column works just fine, thank you.
    Where I might use is some kind of list with many one-two word items.

  6. #6 On December 31, 2005 10:33 AM Matt Robin said:

    (Another) outstanding article from you Andy - do you ever sleep?!
    Column Span - Nuts! Now you're digging up ghosts from the past!!

    "h1 { column-break-before : always }
    h2 { column-break-after : avoid }
    h1, h2 { column-break-inside : avoid"

    This is actually about the funkiest bit of code I've seen for a very long time! I can see this approach getting it's fair share of use in 2006....(note: another prediction!)

    It'll be very interesting to see if IE7 can accomodate the CSS3 spec...(but isn't this jumping ahead a bit? Most sites are still not designed to CSS2 specs yet...I'd expect IE8 to handle CSS3)

  7. #7 On December 31, 2005 02:30 PM Matt Wilcox said:

    I've been thinking about this some more, and I've decided that I want to know how the W3C decide what goes into a spec even more than I want CSS3 to become a usable reality.

    After your suggestion I took a look at some more of the CSS3 spec, and after taking a good look at the template layout module all I could think was "Have any designers voiced a desire to have this? Or is this just a 'cool feature' some code-orientated people have decided to impliment?". I get the feeling it's the latter rather than the former, and that's a little worrying for a tool which is meant for the designer. The feeling is only strengthened when you realise that very basic design options, such as the column-rule-image, are not yet in the draft spec.

    I'd still like to see some basic layout stuff implimented: like the ability to position relative to a named entity instead of a parent element or position in normal-flow. I'd like the choice of that positioned element being re-included in normal flow AFTER it's been positioned too. Being able to do these things would mean an end to having to re-order source code purely to achieve a presentational effect that is otherwise impossible.

    I think there's a lot of CSS3 which is great, and I can't wait to get to play with, but there's still some stuff missing which CSS really needs if it's to achieve it's potential. Template layout isn't one of those things.

  8. #8 On December 31, 2005 07:29 PM Jeff Croft said:

    Column support has definitely been one of the most-repquested features by designers for CSS since its inception.

    I love the idea of columns, but the execution has to be just right for them to work out. If you've got three columns that are, say, 1000px tall, and someone's browser window is only 600px tall, then the process of reading the page goes like this:

    1. Read first column till you hit the bottom of your browser window.
    2. Scroll down.
    3. Read more first column.
    4. Scroll back up to top.
    5. Read second column till you hit the bottom of your browser window
    6. Scroll down.
    7. Read more second column.
    8. Scroll back up to top.
    9. Read third column till you hit the bottom of your browser window
    10. Scroll down.
    11. Read more third column.
    12. Scroll back up to top.

    Smart designers, of course, will use columns that have a height of 100% or less -- but I can see this getting horribly abused by, shall we say, less-informed "designers."

    Still, I'm definitely exciting about the possibilities.

  9. #9 On January 1, 2006 03:45 AM Cedric Savarese said:

    'mysterious frenchman' ?! hey, I like it..

    Thanks for the mention.

  10. #10 On January 2, 2006 11:04 PM Pingu said:

    Yes, it's all very well agreeing that standards should be used and enforced, but the current CSS specs are very poor at supporting things that were simple with tables.

    Why the delay in signing off the specs? Why the delay in discussing them (most ideas could be thrashed out in a few evenings at the pub I reckon).

    It's a bit like IE6 with the W3C. We're all a bit "hello? is there anyone there?"

    IE7, I hear, will only support signed-off specs. Instead of pushing the boundaries (for which they seemed to get slated), they seem to be holding back. I fear us 'real' developers (who have to code designy websites for money) will lose out.

    Can we not get some big-name support for more standards, more ideas (w3c, whatwg etc) and get some cool stuff implemented? Why do we still need all these CSS 'clever tricks' for curvy borders and columns???
    Or will it always take 3 months to design an RSS icon?

  11. #11 On January 3, 2006 04:27 PM Ian Lloyd said:

    You there Andy? You awake?
    Good. So, you comin' to the wedding or what?
    Jeez, the things you have to do to get a confirmation eh? ;-)

    (Ed says: Malarkey says, check your email ;))

  12. #12 On January 4, 2006 05:40 PM Sickbrain said:

    I want to segnalere the translation in Italian of the article of Savarese to the address:

    https://www.sickbrain.org/?document_id=92&topic_id=8&page=0

    Bye :-)

  13. #13 On January 5, 2006 02:01 AM sj said:

    I'm sure this is old news, but the Herald Tribune used Javascript to break their stories into columns - they avoid the issues with scrolling vertically by confining the text to a box with a 'next' link that reveals more of the story. The script is pretty intense and it degrades terribly, but I was still impressed. I wonder if anyone has tried to build off the concept...

  14. #14 On January 6, 2006 02:46 AM Ben said:

    @Pingu: To be fair to the guys on the CSSWG, there's quite a lot involved in signing off a spec (by which I assume you mean it receiving "Recommendation" status).

    A few years ago the W3C reorganised their classifications, because specs were going into Recommendation before anyone was really sure if they were implementable. Therefore what was once called a "Recommendation" is now a "Candidate Recommendation".

    The step from CR to Rec requires two interoperable implementations of each feature in the spec and a full test suite. Test suites take a hell of a lot of time to write. Thus CSS2.1 can't become a Recommendation until it's proven that it can work. What that does mean however, is that browser makers should be looking to implement specs when they reach CR stage, so the spec can be tested. This is precisely what a lot of the -moz- prefixed CSS properties in Firefox relate to.

    Browser manufacturers (namely Mozilla, Opera and Apple as best I can tell, plus the guys who make Prince) are constantly working on implementing CR (and even CSS3 Working Draft) features to work on this interoperability.

    The IE Team did come out with a strange quote a while back about not looking to implement CSS2.1 because it wasn't a Recommendation, which seemed to miss the above point about CRs. That said, I can quite understand that the IE7 team have big issues to fix and catch up on.

    As for the "simple things with tables" point: I agree. CSS Layout as we know it is rather hacky. As best I understand it (and it's very new and very much a rough-draft) the (very) new CSS3 Advanced Layout module is supposed to fix that (as well as providing for content order independence).

    Actually, ’Advanced Layout’ includes the ’Templates’ that Matt Wilcox is questioning further up. Personally, I'm keen to see them developed further and implemented (or at least something which offers the same power they do. The syntax is very rough right now).