cleaning up html pt1
2012 is going to be a good year for html fanatics. Recently I've come across two unrelated techniques that hold great potential for improving the way we write our html. Ironically, both of them are actually css improvements and have very little to do with the html spec itself, but if you've been keeping up with best practices you know that html has suffered some great setbacks the past couple of years. It's time to finally right those wrongs again.
pragmatism massacred our html
Because the complexity of front-end work rose exponentially these past few years, "getting things done" became more important than "doing the right thing". People didn't say that though, they merely called it a more pragmatic approach to our work. To be fair, it sounds a lot better than admitting to sacrificing what you know is right, saving yourself some time in production. Most of these shortcuts were related to css and spilled over to html, changing the structure and mark-up of a page simply to make the css work a little bit easier to manage. Luckily people are constantly working on improving css, which often relieves the pressure on html in the process. In the next two articles we'll see how some of these recent improvements will help to reinstate html best practices.
mixins and skins
The first technique is not so much an addition to the css spec as it is an extra functionality introduced by popular css preprocessors (less/sass). It's a combination of mixins and nesting functionality that gives us the possibility to definee abstractions of visual skins and apply those to root elements that share no common root class. But let's take it one step at a time and start by understanding what this mixin business is all about.
a simple mixin
/* define mixin */ .mixin {border:...; background:...; padding:...;} /* use mixin */ .news {.mixin;} A mixin is written as a simple css class. It is defined by a single keyword (so no complex selectors) and it can be assigned to other css classes. Additionally, the mixin itself can be called directly from the html (since the syntax is the same as a regular css class). Mixins by themselves are interesting in the sense that they can reduce functional or presentational classes (like .hidden or .clearfix) in the html, instead defining them once in the css file where you can reuse them if necessary.
mixins with nestings
/* define skin */ .skin {border:...; background:...; padding:...; header h1 {color:...;} .main p {font-size:...;} footer .more {text-align:...;} } /* use skin */ .news {.skin;} It's no secret that preprocessors allow you to nest selectors, but I think it's not commonly known (at least, I didn't know about it) that these nesting can also be used when defining mixins. The receiving css class will inherit all the nestings, effectively allowing you to define entire visual skins with a single assignment. In the example above we didn't just add styling for the root .news element, but also to a range of nested elements inside the root element.
/* use skin on multiple elements */ .block1, .block2 {.skin;} The interesting part here is that you can assign your skin to multiple selectors at once. So rather than litter your html with classes for styling (oocss), you can make the abstraction in the css file itself. This relieves the html of unnecessary styling classes and takes us one step closer to writing reusable html code.
mixins with nestings and variables
/* define variable skin */ .skin (@color) {border:1px solid @color; background:...; padding:...; header h1 {color:@color;} .main p {font-size:...;} footer .more {text-align:...;} } /* use variable skin */ .news {.skin(#f00;} .block1, .block2 {.skin(#00f);} You can even go beyond and add variables to your skin, making it possible to further theme them and improving reuse of the css. In the example above, .news, .block1 and .block2 are using the same skin, but .news is using a red variant while .block1 and .block2 are using a blue variant.
pitfalls
The fact that skins rely on css preprocessors is clearly not ideal. Surely it will help you out with development of the css code, but the preprocessor will still parse the css before it can be served to the client. This means the bloat is still present, only it's not visible for the developer anymore. Ideally this functionality could be part of the actual css spec so that browsers could do all the processing. This would reduce the bloat and would keep performance fanatics happy.
Even then there is a small performance cost related to the css, as you still need to assign a skin to a selection of root elements (which is not necessary if you take the oocss route). On the other hand, it reduces unnecessary classes in the html so this is hardly worth a second thought.
conclusion
Skins are a great way to make abstraction of styles in css without messing up your html code. It leaves the html code alone and limits the abstraction to where it is supposed to be: your css file. It's a shame that this is only possible using preprocessors for now and that it comes with a (small) performance cost, but the benefits for html are clear and should we ever hope to write robust and reusable html, techniques like these are absolute life savers.