The problem with responsive multiple columnsWhen the multiple column syntax was first introduced, I was hopelessly optimistic about the possibilities that this new layout technique would offer us in crafting good reading experiences.
So far it has been a bit of a let down. Height is the enemy. A vertical scrollbar appearing when multiple columns are in use is an instant fail (in my opinion). That may sound a bit "anti-fold" and that it's leaning towards an argument long settled and forgotten about where layout is concerned. Users scroll. They always do. For a single column of text, users will scroll to continue reading. For multiple columns of text that breaks beyond the viewport, users will scroll to read, then scroll back to the top, then scroll down again (and repeat for the amount of columns being shown) which causes a negative reading experience.
Beyond the Y-AxisIn an infinite canvas, it seems like a shame that 99.9% of the time we only make use of the y-axis. You could say "That's what people are accustomed to, why change that?" - then why change anything? Doing the same thing over and over again isn't going to push our medium forward. Asking difficult questions of the web and pushing it as a medium to uncomfortable places encourages new possibilities.
Multiple columns work better along a y-axis with a defined height. Height isn't our most reliable ally in web design, especially where text-based content is concerned. A fixed height can sometimes mean a premature end to a container with text longer than its constrained parent. A defined height where multiple columns are concerned causes the browser to think horizontally.
When we supply a column-width we don't need to specifiy a column-count. The browser will automatically fill the available space with columns until it doesn't need to create an extra column. This solves the problem of having to specify a width to fit our horizontal columns into. But what about the problem of fitting the columns into a window height?
Finding a height that respondsThe requirement here is to find a measurement that is proportional to the screen. I immediately thought percentages although a percentage-based height simply won't work. The content will break beyond it. We could use pixels to fix the height although we would need countless media queries to change this value when the height changes. What about the vh unit? Support isn't universal, although suprisingly good — it is in IE9+, Firefox 19, Chrome, Safari, Safari iOS, it's even due in the next Blackberry browser! That's good to go in my book, heck - we are building a multi-column layout using native CSS columns, if we have gone this far down that road, why stop now? A positive Modernizr test for vh units would trigger the styles for this setup and then provide a suitable fallback for browsers that can't handle it.
- Provide a height relative to the viewport using vh units
- Specify a CSS column width which will automatically fill the space
- Run a Modernizr test for vh compatibility (if browsers can't read this, then there is no point in continuing with a horizontal layout)
- Editorial bonus specify manual column breaks and remove when space gets tight
Any gotchas?A tiny one that will surely be fixed by browser vendors - when resizing the viewport height, the vh unit value doesn't update - you'll need to refresh the page for it to update. Chris Coyier ran into this problem too when looking at Viewport Sized Typography and filed a bug.
And one gotcha about this demo - I had to remove the Modernizr check for vh because Tumblr wasn't too happy about that script being hosted on this page. Just make sure to include it if you decide to use this approach.