Should you be using a CSS preprocessor? Probably.

We’ve been using CSS preprocessors for some time now but it wasn’t until recently that the reasons for using them really started coalescing for me. CSS preprocessors, like LESS or Sass, basically allow you to write CSS in a more powerful intermediate language which is then compiled down to normal CSS. Like a lot of developers, when I first started using LESS I had some reservations about introducing another layer of abstraction to our development stack. However, after developing a few reasonably sized projects with LESS I’m convinced that using a preprocessor is probably a great idea for many types of projects.

Avoiding the LESS vs. Sass discussion and looking at preprocessors as a class of tools, the clearest benefits are more expressiveness and better reusability.

More expressiveness

As a language, CSS is amazingly straightforward, it basically consists of selectors and rules which are written in flat, plain text files and then combine to style your HTML. Since there are no constructs for variables, conditionals, or functions writing CSS is simple – just fire up and editor and start making changes. The ease of writing and understanding CSS is certainly a benefit but it comes at the price of sacrificing how expressive the language can be.

Using selector specificity as an example, the benefits of the preprocessed files are clear.

Using regular CSS you might end up having rules that look like:

Versus the corresponding LESS:

Looking at the two examples, the LESS uses its structure to express how the nesting rules work and because of this has a higher information density than the regular CSS.

Another common issue where increased expressiveness is helpful is in writing semantically meaningful CSS class names. With regular CSS, the tendency was to normally end up with CSS rules that end up looking like:

The trouble of course being that the CSS class names are tied to their physical appearance as opposed to what they actually mean in your app. Although its possible to write semantic class names in vanilla CSS, the difficulty arises when you’re trying to uniformly apply things like colors, padding, and borders across a range of elements. Without variables and mixins it becomes significantly harder to manage or change these semantically named classes. Looking at how Twitter Bootstrap defines buttons, its clear how much more expressive the declarations are by keeping the colors in easily changed variables:

Better reusability

Another benefit which preprocessors introduce is better code reusability. Although CSS has imports, the amount of code which you can functionally reuse is pretty limited since existing rules can’t be included into new ones. The best you can really hope for is being able to reuse a common stylesheet across projects. Comparatively, preprocessed CSS offers mixins and functions both of which foster more reuse.

Some of the best real world examples of this are in the Twitter Bootstrap mixins.less file which includes mixins used throughout the framework. Additionally, projects that build upon the Bootstrap framework would also be able to leverage any functions or mixins Bootstrap defines further increasing reuse.

Anyway, looking at the benefits compared to the overhead of involving a preprocessor I think for any reasonably sized project you’d almost always be better of developing with one. It’s obviously going to come down to the specific project but I’d be interested in hearing everyone else’s opinion.

Be Responsive: A History of Responsive Design

During the last two years the number of mobile devices has grown at an exponential pace, with one Cisco estimate ( predicting more mobile connected devices than people by the end of 2012. Due to this growth, providing a first class mobile web experience has become increasingly important and is now a paramount concern for websites. Union Square Ventures’ Fred Wilson went as far as to point out that new web apps are commonly designed “mobile first web second” (

Within the last year a technique known as “responsive design” has become an increasingly popular way to tackle “mobile vs. desktop” web design issues. There have been several reasons for this rise in popularity which we’ll talk about after an abridged history of the mobile web.

How did we get here? Well it all started with WAP… Back in the dark days of the mobile web, well before the average consumer was accessing the Internet from a cellphone the majority of web content was served via a technology called the Wireless Application Protocol. Even I am to young to really have experienced it in all of its glory but the “Criticisms” page on Wikpedia should convey just how awful it was – Big takeaways? Imagine writing websites in XML, oh and it has to validate.

Anyway, fast forward a couple of years and vaguely recognizable devices are slowly starting to come online. From the Nokia Symbians, to Palm, and of course the venerable Blackberry mobile devices are beginning to access the nascent mobile web (yay!). The problem? The browsers on these devices were severely limited in terms of CSS and Javascript support, standards compatibility, and available bandwidth. As a result of these limitations, developers chose to basically develop “stripped down” basic HTML versions of sites to present on mobile devices.

One last trip in the DeLorean and we’re zooming from the initial release of the iPhone during the summer of 2007 to today with thousands of smart phone and tablet models and billions of connected devices. During this period, developers tended to build specific “mobile” sites which were usually an entirely separate HTML/CSS/JS(kinda?) code base from their desktop sites. Understandably, this situation was less than ideal since at the minimum it meant maintaining two code bases and the mobile site often lacked the full functionality of the desktop site. Additionally, as both desktop and mobile browser development rapidly progressed consumers began to expect a consistent experience across their devices.

So how do we address these issues and improve mobile user experience? Enter, “responsive design”. The central tenant of responsive design is that you (the designer/developer) should be able to use the same HTML, CSS, and Javascript to serve devices with different screen sizes and resolutions. The idea is that your layout should be able to respond by adapting the it’s presentation layer depending on any number of factors.

The key technology this process relies upon are Media Queries. Fully adopted by CSS3, media queries allow CSS directives to be conditionally applied depending on the result of a boolean query. In practice, this means a single CSS stylesheet can contain one set of directives for a 480px screen as well as different directives for a 1200px screen. Lets look at an example. If you open and then progressively shrink your browser window you’ll see that the elements dynamically adjust depending on the size of the screen.

Well that’s some history and a quick demonstration, now for some nitty implementation gritty details. Unfortunately, there’s no “magic bullet” to automatically take a standard desktop layout and responsively adapt it for different screen sizes. In my opinion the best approach is to start with a solid framework, keep your markup clean, and of course be cognizant that you’re planning to adapt the layout for different screen sizes. Or if you’re feeling brave, start with the mobile layout first and then progressively enhance the layout as your screen size increases.

Here are some specific resources to get started: