Semantic CSS grid layout with LESS

Semantic CSS grid layout with LESS

I have a confession to make. After eight years since we first met, I still don’t quite get CSS.

Sure, I can do typography, sprite backgrounds and understand the basics of the box model. I even know about browser-specific CSS extensions for CSS3 effects. But when it comes to clearing floats, vertically-aligning form elements or figuring out inline parents with block children, I go to a very dark place and start cursing.

I freely admit my CSS layout and positioning skills are lacking, and I probably shouldn’t even be blogging about it. But when I discovered CSS grid frameworks, I was naturally interested — anything that helps me get up and running quicker in a foreign language is a win.

Grid frameworks: CSS for dummies

For those that don’t know, grid frameworks like 960gs, YUI grids and Blueprint CSS provide a simple 12, 16 or 24 column grid that abstracts away complicated CSS layout and positioning rules.

For example, using the Blueprint CSS framework, this markup produces the following layout, neatly centered in the middle of the browser window:

<html><head>    <link rel="stylesheet" type="text/css" href="blueprint/screen.css" /></head><body>    <div class="container">                <div class="push-4 span-15">header</div>                <div class="push-4 span-4">menu</div>                <div class="span-7">main</div>                <div class="span-4">ad space?</div>                <div class="push-4 span-15">footer</div>    </div></body></html>

How easy was that? As a CSS newbie, not having to worry about floats, clears, negative margings and other positioning tricks is a very attractive proposition.

So CSS grids are very powerful for quickly laying out elements. But there is a trade off you should consider — HTML marked up with grids is not at all semantic. Peppering your HTML with classes like .span-12 or .yui-t3 for layout is no better than specifying table widths and heights everywhere.

Wouldn’t it be great if you could keep using these grid classes, but somehow mask them behind semantic class names?

LESS: CSS preprocessor

About the same time I discovered grids, I stumbled upon LESS: a ‘leaner’ CSS command-line preprocessor that extends CSS with its own syntax and features. The .NET port, .Less, has a smaller feature set than the rails version, but it lets you do stuff like this:

.rounded_corners {        @radius: 8px; /* variables */        -moz-border-radius: @radius;        -webkit-border-radius: @radius;        border-radius: @radius;}#header {        .rounded_corners; /* mix-ins */        img.logo { /* nested styles */                margin: (@radius * 2) + 1px; /* expressions */        }}#footer {        .rounded_corners;}

I have .Less is setup as an HttpModule in my web.config. It intercepts any requests to *.less files, translates them to real CSS, and optionally minifies (compresses) them. So you can you can simply reference the .less file directly in your markup, with no extra compilation step required:

<head>    <link rel="stylesheet" type="text/css" href="site.less" /></head>

Grid CSS frameworks + LESS = semantic grids

I’ve been using LESS for a few weeks now, and to be honest, I never want to go back to writing ‘raw’ CSS again. So what happens when you combine the CSS grid framework with LESS? Here’s the new stylesheet:

@import blueprint/screen.css;div.container {        div.header {                .push-4;                .span-15;        }        div.menu {                .push-4;                .span-4;        }        div.main {                .span-7;        }                div.ads {                .push-4;        }                div.footer {                .push-4;                .span-15;        }}

All that’s left is semantic class names using grids styles as mix-ins. Now the markup is looking acceptable again:

<html><head>    <link rel="stylesheet" type="text/css" href="site.less" /></head><body>    <div class="container">                <div class="header">header</div>                <div class="menu">menu</div>                <div class="main">main</div>                <div class="ads">ad space?</div>                <div class="footer">footer</div>    </div></body></html>

Using grid classes as mix-ins gives us the best of both worlds — you get the power of the grid CSS framework, but without introducing layout concerns to your markup.

IUnityContainerAccessor must use a static container instance

IUnityContainerAccessor must use a static container instance

I found an interesting problem this morning when my ASP.NET MVC application mysteriously broke after adding an HttpModule in the web.config. Here’s the problem code:

public class MvcApplication : HttpApplication, IUnityContainerAccessor{    IUnityContainer container;        public IUnityContainer Container    {        get { return container; }    }    public void Application_Start()    {        this.container = new UnityContainer();        // this.container.RegisterTypes etc    }

The container was being configured fine in Application_Start, but then UnityControllerFactory would throw “The container seems to be unavailable in your HttpApplication subclass” exceptions every time you tried to load a page — this.container was somehow null again.

After doing a little digging and finding this article where someone had the same problem with Winsdor, it seems ASP.NET will create multiple HttpApplication instances when parallel requests are received. However, Application_Start only gets called once, so anything you would like to share between multiple instances (e.g. your IoC container) must be static:

public class MvcApplication : HttpApplication, IUnityContainerAccessor{    static IUnityContainer container; // good    IUnityContainer container; // bad, not shared between HttpApplication instances        public IUnityContainer Container    {        get { return container; }    }

St9exception with libstdc++

St9exception with libstdc++

Here’s something I encountered today when writing some C++:

try{    throw std::runtime_error("some message");}catch (std::exception e){    std::cout << "error: " << e.what() << std::endl;}

When run, this code will write “error: St9exception”, instead of “some message” to stdout. “St9exception” comes from libstdc++, in which the default value returned by std::exception::what() is the mangled symbol name. The mistake was that I was catching the exception by value, not by reference. (Too much C# perhaps?)

Instead it should have of course been:

try{    throw std::runtime_error("some message");}catch (const std::exception & e){    std::cout << "error: " << e.what() << std::endl;

BarCamp Agile Wellington

BarCamp Agile Wellington

This Friday I will be attending my first BarCamp here in Wellington. A BarCamp is an “open source” workshop-style event that focuses on user participation and freedom of information.

Mike Riversdale (who I worked with briefly at the Christchurch City Council last year) is running BarCamp Agile Wellington on Friday December 6 at Deloitte House. The theme is Agile and will include seminars on related topics like Scrum and Lean, and how they can be applied to other disciplines such as project management and information architecture.

Mike has assured me that BarCamp’s Fight Club-style “everyone must present” rule will be relaxed, which is lucky for newcomers like me!