Dynamic50 Web Design and Development, Ruby on Rails Specialists in London and Oxford, UK

Wouldn’t it be nice to be able to use multi-column layouts in our sites, without resorting to using a silly amount of divs and javascript? Well, that’s what the Multi Column Module of the CSS3 spec aims to do. It has been in “Working Draft in the CSS Working Group for several years” and has only just coming out of ‘Last Call’ status. There is still a lot of stuff to be ironed out, but doesn’t mean we can’t start having a wee poke around.

As a quick aside, the motivation for this post came after attending the ‘Advanced CSS Styling’ workshop, one of Andy Clarke’s “For a Beautiful Web” branded workshops. If you do have to chance to attend one of Andy’s workshops, I would highly recommend it. Traveling up to Newcastle and back down again was a bit of a drag (and expensive), but if you are in the area, then it’s pretty good value.

Anyway, back to columns. Multi-columns (or a subset at least) have been supported Firefox 1.5 and Safari 3, via -moz and -webkit vendor prefixes respectively. IE and Opera users are out of luck at the moment. Quite a lot has been written about using CSS3 columns already, for example this article by Andy Clarke himself or this one from A List Apart, so I won’t repeat too much, as they can explain things much better than I can.

What I am going to explore is what happens when you start over specifying column properties. It’s not something that has been covered too well, but well worth exploring as different browsers seem to do different things. There are 2 ways to make use of columns- define the number of columns you want using (column-count:), or define the minimum width of the columns (column-width:) which generate the correct number of columns to for the container. What happens then, if you specify both? The spec says that in most cases, if both are non auto values, then the column-count should be ignored. I have found the opposite to be true in the implementation by current browsers (Firefox 3.5, Safari 4).

The markup:

div.multi-column{
  -moz-column-count: 3;
  -webkit-column-count: 3;
  column-count: 3;

  -moz-column-width: 10em;
  -webkit-column-width: 10em;
  column-width: 10em;

  width: 550px;
  border: 1px solid #000;
}

The results:

Firefox 3.5

Safari 4

As a control test, here is the same, but without the column-count (i.e. what the broswers should be doing).
The markup:

div.multi-column{
  -moz-column-width: 10em;
  -webkit-column-width: 10em;
  column-width: 10em;

  width: 550px;
  border: 1px solid #000;
}

The results:

Firefox 3.5

Safari 4

As we can see here, with both rules in place, the column-count rule is definatley not being ignored, though it is handled differently by our Gecko and Webkit browsers. Firefox seems to be actually ignoring the column-width value, while Safari seems to be enforcing both, resulting in a bunch of unused space to the right.

The only times when both sets of values should be enforced are when they are applied to an element without a determined width, such as a floated element or table cell with no width value. In these cases, the width of the element should be shrunk to fit.

div.multi-column{
  -moz-column-count: 3;
  -webkit-column-count: 3;
  column-count: 3;

  -moz-column-width: 10em;
  -webkit-column-width: 10em;
  column-width: 10em;

  float: left
  border: 1px solid #000;
}

Firefox 3.5

Safari 4

Firefox does indeed shrink to fit, while Safari seems to be taking up the width of the parent container. Further investigation though reveals that Safari actually is shrinking to fit, though in a different manner from Firefox. If we shorten the content so it doesn’t line wrap, we see what is going on. Consider these image taken from Firefox and Safari, each has 2 boxes of identical content, the only difference being that the second box has no multi-column values.

Firefox 3.5

Safari 4

So what’s going on here? It seems to while that while Firefox determines the width of the floated element by adding the values of border, padding, col-widths and col-gaps; Safari on the other hand determines the width from the content without columns and then applies it’s column rules on top of this. I really don’t have any confirmation that this is what is going on, but that is what it appears to me.

Now the amazing thing is, is that neither of these approaches are wrong. In reference to ’shrinking-to-fit’, “CSS does not define the exact algorithm“. While the Firefox method seems more intuitive, it does not mean that the Safari implementation is wrong, at least not that I can interpret. This may well be a moot point though, as floated elements really should have an explicit width set.

So far, we have left the height at auto, so that it is determined by the text in columns. When we do set a height, we get a similar sort of behavior to with an auto height.

div.multi-column{
  -moz-column-count: 3;
  -webkit-column-count: 3;
  column-count: 3;

  -moz-column-width: 10em;
  -webkit-column-width: 10em;
  column-width: 10em;

  width: 400px;
  height: 200px;
  border: 1px solid #000;
}

Firefox 3.5

Safari 4

In Firefox, when we do set a height- it will draw up the box accordingly, use the column-count value to determine the number of columns, unless column-count is set to auto, in which case it will use column-width to determine however many columns it needs. It then starts filling these column-boxes with content, and will carry on doing so, overflowing the content in the X axis if needed.

In contrast, Safari will draw up its box, use the column-width, if not set to auto to determine the number of columns, and fill in the content, overflowing in X axis if needed.

I haven’t got round to exploring setting column-widths, columns-numbers, width, height and floats; but my head hurts a bit already- so I’ll leave that to you all…