Over a million developers have joined DZone.

Improving The Blacklabel CSS - Dealing With Images

DZone's Guide to

Improving The Blacklabel CSS - Dealing With Images

· Web Dev Zone ·
Free Resource

Jumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.

If you haven't read my article on blacklabel css files yet, now is the time. This article will propose an improvement on working with these types of stylesheets, so if you have no clue as to what they are all about, all of this will be pretty useless. In this article I will explain the problems with the initial concept and how we can work around those problems. Time for some magic.

Blacklabel Troubles

If you remember well, the purpose of the blacklabel css is to construct a design without the final touches, so derivative designs can easily be made and maintained. Colors, font-styles, borders and the like were banished to a specific css file for each derivative design. Margins, floats and all other structural css declarations were placed in the blacklabel css file.

I don't suppose many of you have had the pleasure of trying out this method already, but I got started on it right away. After a good day's work I came to realize that there were still some issues that needed resolving. While I had hoped for the specific css file to become an overview of "things that need changing to create a derivative design", it became littered with background-image declarations, completely messing up my sweet and theoretical concept.

Now, if you remember my initial concept, background images belong in the specific stylesheet. With the setup I was using though, the image declarations for each derivative were exactly the same. They referenced the same relative path, but as each specific css file was in a different physical location they referenced a different file. Putting those declarations into the specific css clashed with the idea that these css files would only contain elements that needed adapting for each derivative.

Time For Some Analysis

The problem was actually pretty clear. The background image declarations belonged into the blacklabel css, I just had to find a good way to have them reference the correct image. Of course, this only works when the declaration of the background image is identical for each specific stylesheet.

In reality, this means one folder for your blacklabel design and one separate folder for each derivate design. All folders should be structured in the same way, containing an image folder bearing the same name and containing images bearing the same name. If you set it up like this, you'll see that the background image declarations will become identical for each specific stylesheet, making it possible to ship all those declarations to the blacklabel css.

This just leaves us the issue of obtaining the right file. After asking around a little bit I came up with two possible solutions, which both proved useful. Both solutions require you to do some server tweaking though, so if you're just a simple html/css guy like me you should probably ask for some extra guidance.

Creating An Alias In Your Webserver

An alias is comparable to a shortcut, only smarter. While a shortcut only refers to a file somewhere else on a file system, an alias pretends the file is actually in the alias location. This means that all relative paths will be applied from the location of the alias, not of the source file. An isn't that exactly what we are looking for.

example: Alias /image /ftp/pub/image -- A request for http://myserver/image/foo.gif would cause the server to return the file /ftp/pub/image/foo.gif.


By providing an alias for the blacklabel css in each derivative folder, we can add the background image declarations in the blacklabel css file while still referencing the image folder of the derivative design. Swell!

More information on aliases is available on apache.org.

.htaccess File

The alias solution is nice but requires you to make one alias per derivative design. Not always the cleanest solution, especially when new derivatives are made afterwards (making maintenance a little harder). Another way of fixing things is by doing a very similar thing, but now using .htaccess files. Rather than make one alias for each derivative, we brew together one rewriting rule that will fix it for all.

RewriteRule ^(.*)style-admin/onderhond.css$ /style/onderhond.css

The rule above is one I will use on the latest version of my blog. It redirects the onderhond.css file in the style-admin folder to the one in the style folder. If you look in the directory structure itself, you will find no onderhond.css file in the style-admin folder, though the css will behave itself like it was actually there.

More information on .htaccess files and rewriting can be found on askapache.org.


Both solutions above are for Apache web servers, but similar solutions can be found for other web servers too. I haven't gone into much detail about the actual solutions as I simply lack the knowledge to explain they in fine detail, but this article should give you enough info to start tweaking yourself (or to bug some guys around you who do know about this kind of thing).

Anyway, by using this trick you can offload all your background image declarations to your blacklabel css so they won't clutter your specific css files anymore. It makes them a lot easier to adapt and much nicer to maintain. The only limitation is that you keep an identical folder structure for each derivative, but that should be quite easy to accomplish.

I've been applying this technique a couple of times now and the result is pretty interesting to behold. My backoffice was completely restyled this way and was given a complete color-invert look by simply changing some color statement in the specific css.

Feedback on the blacklabel css idea and how to improve it further are more that welcome!

Take a look at an Indigo.Design sample application to learn more about how apps are created with design to code software.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}