Start coding today to experience the powerful engine that drives data application’s development, brought to you in partnership with Qlik.
The idea of having variables in CSS has been something that developers and designers have argued about since the very beginning of CSS. Like the PC vs Mac debate, there are many passionate folks both for and against variables and both groups have some valid opinions and concerns. This debate was re-ignited with the recent release of a draft of the new CSS variables module.
Fortunately, as developers and designers we have the opportunity to influence the people who write the specifications. This draft is an early stage document that will undergo a variety of revisions before it can even be considered for spechood. For this reason, I feel it’s important to voice my opinion.
As a developer who works on everything from small wordpress sites to large enterprise apps, I am in favor of CSS variables. While I believe the implementation outlined in the spec could use some polishing, the core concept is a great boon for those of us managing large, complicated stylesheets. If this becomes part of the spec, it will be a large step toward making CSS slimmer, easier to maintain and adhere better to DRY coding practices. Simply put, for those of us that understand CSS, this will enable us to write better CSS and as a result build better websites.
While there are many that dislike the idea of CSS variables, it seems that the single largest complaint is that it would make things more complicated and harder to learn. Personally, I don’t think this is accurate for several reasons:
- CSS variables will allow developers to simplify their CSS immensely and write less code. It has been my experience that simple code built on complex concepts is no harder to learn than overly verbose code that might be simpler conceptually.
- One of the greatest benefits of CSS is that properties cascade in a predictable manner. It’s so important that it got its own letter in the name. Variables allow this concept to be applied in a great variety of situations.
- Above all else, it’s optional. If this becomes a spec, there is no reason that everybody must use it. If you’re happy without variables, keep on being happy without them. Nobody is taking away anything from the language, just adding a new tool for those that need it.
Now that I’ve clearly stated my position, I would like to point out what I believe to be a flaw in the current draft. The data prefix seems unnecessary. Having a single character, such as $ or @ or even § would be better. Ok, maybe not §, but many languages and libraries have established that a single character to denote variables works well. Not only does a single character result in less typing, it also makes it easier to quickly identify variables when scanning through a stylesheet. To me @primary-background stands out more than data-primary-background when viewed along with hundreds of other properties.
This draft does have a few flaws, but overall it is a step in the right direction. It can provide a powerful new tool for those of us that manage hundreds and possibly thousands of lines of CSS and I see no reason why adding a new feature would make any of the existing features harder to learn. The fact that tools like LESS have caught on shows that there is a real need for features like this. When we choose to block potentially powerful new options simply because it is difficult to learn, we cheat those that might use it to build something amazing. We overcame the IE6 box-model and crafted amazing layouts using only floats, there is no reason why we can’t learn how leverage this new functionality to our benefit.
What do you think? Is this new module a great new tool or a disaster waiting to happen?
Create data driven applications in Qlik’s free and easy to use coding environment, brought to you in partnership with Qlik.