The trick is that my output document in HTML5 is now ridiculously well-formed. There are named tags in places that make sense, and there are very, very few <div> tags in the output. You might expect this to be great for HTML, but not so good for CSS. In actuality, it was necessary to add only one additional div to the output to conform to the layout that the grid in bootstrap requires. That's pretty neat.

But then I started to think about what I would need to do to apply bootstrap to my template. Basically, it would require me to add all sorts of classes to my semantic tags, and this bothered me. For example, I have a section with an id of "posts" that contains the main blog content, and an aside with an id of "sidebar" that contains the sidebar. If these things already have tags and id's that represent them well, why would I want to add classes to them to define how they should look presentationally? Should I not be able to address those elements directly?

This leads to what I think is an interesting - and for me and Habari, age-old - discussion about the efficacy of CSS frameworks. Frameworks are great if you want to quickly apply a framework's layout to your existing design. They provide a great foundation in which you can see your site become pretty quickly. But ideally, custom CSS is a better way to go. If I never use the "span8" class, why would I include it in my CSS? And the class names are certainly of no use to my markup. Moreover, if I want to re-style a template by swapping out CSS, embedding the widths of the columns into the markup (with the "spanX" classes") would prevent me from easily making layout changes.

What I wanted to do with LESS, or what seemed possible, was to use mixins. After all, if I can say that an element with the id of "posts" includes all of the properties of the class "span11", then I've basically succeeded at using the framework effectively for rapid layout, and keeping my markup semantic. Right?

Well, that doesn't work. Why? There are a couple of reasons but primarily, the mixins add the referenced rules into the new selector, but they do not alter other uses of the referenced rule to be influenced by the new selector. This is probably best explained with an example.

If I have this LESS code:

.foo { color: red; }
.foo .bar { text-align: left; }
#posts {
.foo;
}

You might expect there to be a new rule in the processed CSS output like this:

#posts {
color: red;
}

There is! Which is great. But what I was also hoping for was this:

#posts .bar {
text-align: left;
}

And of course, it doesn't make any sense to expect this, because I didn't write a rule that explicitly defined this on the child class. But this is what I wanted it to do. Bootstrap is riddled with little tricks like these, especially in the complicated grid rules, that includes selectors like .row > [class*="span"], which selects an immediate child element of an element with the class "row" that has a class starting with the word "span". Obviously, unless I redefine this rule it's not going to do anything for me.

I thought a bit about what I would really want instead of this. What I think I would like is a CSS framework that allows me to use it for output like LESS and SASS, but also expects that I'm not going to use it forever; that I would really like to graduate to full-on compiled and minified CSS that doesn't include all of the cruft that the framework comes with that I don't use.

I can't see any way to get what I want using LESS and Bootstrap. Both tools make it easy and fast to get a layout up and running, but even combined, neither is very good at producing the CSS I would most want for my semantic HTML. What I would like most as a new feature would be to see a command that allows me to specify two selectors and have the compiler replace one with the other entirely in the output. In this way, I could keep the bootstrap source and add my own styles and keep my HTML5 markup nice and clean.