I’m a big fan of Twitter’s Bootstrap html/css/javascript framework, and use it on practically all new web projects that I work on. It makes it super easy to quickly knock up a slick-looking web application, and since it’s built on less it’s really easy to customize the look of each site.

That said, the markup is complex enough that when developing sites I typically have the docs open in another tab at all times as a reference point, which lead me to start building little HtmlHelper extensions to create the more complicated elements, such as navbars, forms, etc. These extensions have been bounced around from project to project, and have ended up a little scrappy as they’ve been built as-and-when with no real planning, but they have been hugely useful, so I decided it was finally time to look at rewriting them. Check out the Bootstrap Extensions repo over on GitHub, or have a browse through the documentation (design somewhat inspired by the original bootstrap docs!).

The library is by no means complete, as of writing this I’ve only implemented lists, buttons, button groups + toolbars, navbars and progress bars; but it’s a start, and I intend to cover the majority of the more involved elements. I’ll also look at fine tuning the API to make development as pleasurable as possible.

Update: This project has been included on The Big Badass List of Twitter Bootstrap Resources. Check it out, there’s some brilliant useful stuff on there

TL;DR – Solution Below

Version 2.1.0 of Twitter’s awesome css/javascript framework Bootstrap was released a couple of days ago, and so I took the opportunity today to upgrade a few of our projects that are using it from version 2.0.4. We take full advantage of Bootstrap by using less css, and compile it with .less (pronounced dotless, and conveniently available via NuGet); not only to ease with customization, but also to allow use of the helpful mixins provided.

Unfortunately, there are (at the time of writing this) errors in the v2.1.0 less files, and when I replaced them the pages rendered with no styling, and inspecting the compiled files showed that they were being returned as blanks.

Step 1: The Binary Chop

I’ve never had to diagnose .less errors before, my prior experience has pretty much entirely consisted amending existing less files and throwing mixins into my styles, so the debugging process started – as so many hacky debugs do – with the binary chop. Although it’s not a pretty debug technique, it did enable me to quickly find that the issue was caused by the variables.less file. Unfortunately (thought it’s behaviour we’d usually want), .less caches the compiled css, and so a rebuild was required after each change to regenerate the css.

Step 0.9: Disable Caching

Man I wish I’d known this one before beginning step 1. We installed .less using NuGet, which adds the correct configuration to the Web.Config which makes it all Just Work – which is a great thing, but came round to bite me when I realised that I’d never actually taken the time to look it.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <section name="dotless" type="dotless.Core.configuration.DotlessConfigurationSectionHandler, dotless.Core" />
  </configSections>
  <dotless minifyCss="false" cache="true" />
</configuration>

cache=”true” !? Oops, turned that off. Great, no more rebuilding!

Step 2: Closer Look at variables.less

So I knew where the problems were in , but still didn’t know what the problems actually were. Unfortunately, this required more hacky debugging, commenting out code to make it compile and uncommenting it chunk-by-chunk until it broke again. I quickly found the first error, in the Navbar variables:

// Navbar
@navbarBackground:                darken(@navbarBackgroundHighlight, 5%);
@navbarBackgroundHighlight:       #ffffff;

See it? The issue is caused by the @navbarBackgroundHighlight variable being used before it is defined. To be honest I’m not entirely sure whether this is a less syntax error, or with the .less compiler implementation, but it was this that was causing the compiler to return blank css.

This was an awkward thing to find, and I expected that since it was in the code once, there were probably multiple instances of the bug, and so I decided that it was time to look into seeing if it was possible to log .less compiler errors.

Logging .less Compiler Errors

It was possible, and really easy – just a touch more configuration needed in the Web.Config:

<dotless minifyCss="true" cache="false" logger="dotless.Core.Loggers.AspResponseLogger" />

Even nicer, I’d expected the errors to be logged to disk somewhere, but conveniently they were viewable in the bootstrap.less file when inspecting it in the browser, and as expected this made it really quick and easy to identify and fix the errors.

variable @dropdownLinkBackgroundHover is undefined on line 94 in file 'less/dropdowns.less':
[93]: background-color: @dropdownLinkBackgroundHover;
[94]: #gradient > .vertical(@dropdownLinkBackgroundHover, darken(@dropdownLinkBackgroundHover, 5%));
------------------------^
[95]: }
from line 94:
[94]: #gradient > .vertical(@dropdownLinkBackgroundHover, darken(@dropdownLinkBackgroundHover, 5%));

Final .less Config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <section name="dotless" type="dotless.Core.configuration.DotlessConfigurationSectionHandler, dotless.Core" />
  </configSections>
  <dotless minifyCss="false" cache="false" logger="dotless.Core.Loggers.AspResponseLogger" />
</configuration>
Update: Before writing this blog post I filed an issue on the Bootstrap github, and less than five minutes after finishing it the issue was closed: it seems the variable ordering bug was found and fixed already. Still, I’m glad it gave me the opportunity to dig deeper into debugging .less