So in a previous post I talked briefly about my ‘wishlist’ for CSS3 (or beyond) – additions to the language that I would really like to see implemented in order to give us a better, more flexible way of tackling a wide variety of issues.
Out of the five things I mentioned – Basic math, delegation, positioning model tweaks, constants, mixins – the last two are perhaps the most straightforward. Whilst in the post I talked about better tools for problem solving, variables and mixins are really more about being able to write cleaner, more maintainable and flexible CSS code with a better separation from the associated HTML.
I’m going to go into a little more detail on what I actually mean when I talk about variables and mixins in CSS, how they could help us write better code, and why they haven’t yet been (and may never be) implemented.
Constant Variables
Before I start talking about variables in CSS, a quick word on terminology: I use the term ‘variables’ here because it has gained some popularity, but it would really be more correct to describe them as ‘constants’; their value, once assigned, is not expected to be mutable over the course of the document.
So, the basic concept is that you would be able to define a variable that holds a value (such as a hex colour, or a width) and then be able to use the name of that variable to refer to it later on in the stylesheet. So you could do something like this:
@variables {
myCompanyBrandingColour: #F00;
myCompanyFonts: 'Comic Sans', Arial, sans-serif;
}
#header {
background-color: var(myCompanyBrandingColour);
}
p {
font-family: var(myCompanyFonts);
{That way, when your company rebrands, to change the branding colours and fonts throughout the site you would be able to update the value of just one or two variables, rather than having to trawl through your stylesheets looking for instances of that colour or font-family.
Sounds good doesn’t it? This idea is certainly not new, and has cropped up repeatedly in one form or another over the last ten years or so. A few members of the W3C have even written a detailed spec for it, and it was even implemented in Webkit nightlies for a while (it was removed because it’s implementation in Safari would have been “hugely popular“, but they didn’t feel confident enough that the spec wouldn’t change in the future and thus leave them having to support an outdated implementation).
Yet this concept keeps on getting repeatedly shot down on mailing lists and influential people in the W3C such as Bert Bos (one of the original formulators of CSS, nonetheless) have written at length about why this idea will not get included in the spec anytime soon, if ever.
This is a real shame, in my opinion. There is a clear demand for this feature in CSS, and the arguments made against it just don’t work for me. Some of Bert Bos’ arguments in the aforelinked essay seem almost laughable:
“…it is quite likely that somebody who is trying to learn CSS will give up learning it when he sees that style sheets that occur on the Web don’t actually look like the tutorials he started from.”
…which sounds like an argument against progress in any web development language (or in any other programming language at all for that matter!) and is clearly nonsense – what about all the new additions to CSS to be implemented as part of the CSS3 spec, for instance?
He also talks about the ‘implementation effort’ of including variables/constants in CSS. This is another argument that I have no time for – I just don’t think that (within reasonable limits) the W3C should be concerned with how difficult features are to implement. The Webkit nightlies implementation has already shown that this is achievable, and if this was to be included as part of the official CSS spec then I have no doubt that browsers manufacturers would scramble to implement it, effort required or not.
The only serious issue with this idea, in my mind, is backwards-compatibility. Older browsers that didn’t support this feature would ignore rules specified in this way, so there would need to be some way of providing a fallback. I’m confident an acceptable solution can be found to this; and in the meantime at least if there was a officially supported spec then the gap could be temporarily filled with ’standards compliant’ CSS pre-processors, rather than having the mishmash of non-compatible CSS pre-processor implementations that we have today.
Mixin it up
So, on to mixins. A mixin is an author-defined rule-set that can be ‘mixed-in’ to other sets of rules for particular selectors. The LESS CSS pre-processor implementation of mixins looks like this (from their documentation):
.bordered {
border-top: dotted 1px black;
border-bottom: solid 2px black;
}
.post a {
color: red;
.bordered;
}What is happening here? Well firstly, we are defining a rule-set with a class selector of ‘bordered’ in the usual fashion. Then, in the .post a rule-set you can see that the class name has been used inside the braces – indicating that the rules defined in the .bordered class are to be imported into the .post a rules at that point.
It’s possible to do something very similar to this today; in fact I use it all the time – I split my rule-sets up into discrete chunks using class names, and then apply those one or more of those classes in the HTML markup to achieve the desired result. However, this has one big problem associated with it: it breaks the paradigm of the separation of style and content, and ties our markup and styles together in a way that wouldn’t be necessary if we could use mixins in our CSS.
Again, there are many people both for and against the ideas of mixins being added to the CSS spec. In fact, Bert Bos’s arguments in his article could probably be equally applied to mixins. However the advantages of having the ability to be able to define class-based style rules and then have them available to use as part of compound rule-sets seem obvious to me; helping us stick closer to DRY principles, reducing maintenance, helping to ensure consistency within sites, and removing a common dependence on markup would all be good things, would they not?
In summary
What I would like to see is a way to cut down on the amount of CSS I write, and make it more portable, more flexible and more maintainable. I think that variables and mixins in CSS would help that become an achievable goal. There are many others who feel similarly; I just wish that it didn’t seem like the W3C had completely closed out the subject of additions such as these to the CSS language.
No Comments »