on css variables, mixins and nesting
Last week the news broke that work on css variables was resumed. Nothing too official yet, but people felt it was time to give it another go. Not too much of a surprise, similar frameworks like SASS and LESS are gaining momentum quite rapidly, but not everyone is happy with the addition of variables (mixins and nestings) in native css. At the core of this schism lie crucial fundamentals of css, so let's see what's holding people back to turn css into a more program-like language.
css variables, mixins and nestings
For the full specifics and syntax proposals I'm simply going to refer to an article written by Johan Brook. He does a pretty good job of laying down the basics in a very organized and easy to understand manner. To me this article is not about syntax proposals or providing reference material, it's about coming to a conclusion whether to adopt these changes or whether to refute them.
In short, css variables will substitute a single css property value for a variable name. Changing the value (on top of the css file seems like a logical place) will change the values everywhere this variable is used. It sounds quite fancy, but in most cases it's nothing a well-aimed "replace all" couldn't fix. Mixins are a little fancier, bundling a set of css properties which can be used for further reference throughout the stylesheet. Powerful stuff, but potentially quite messy. As for nesting, they are all about reducing selector length and ease of adaptation when a class name is changed in the html code.
While these three techniques are not inherently connected to each other, they seem to be grouped together as one single proposition, so for the time being I'll handle them as such.
css ideals
Just like html, css was conceived to be a simple language. A pick up and play kind of tool that would be promoted to reach a broad audience. The web was meant for everyone and so css should be a language that anyone with a healthy interest would be able to pick up quite rapidly. If you look at the everyday difficulties you're experiencing with css this might provoke some cynical laughter, but know that most of your troubles are due to browser incompatibilities, not because of the spec itself.
Also, just like html, css is meant to be as backwards compatible as possible. We cannot break the web when we introduce new properties and property values, and if we do we should at least have workable fall-backs available. This can be quite infuriating at times, no doubt, but it's a core principle we can't simply ignore. Even if it would make our job a whole lot easier, we'll just have to cope with these basics as they are for the greater good.
Both principles seem to suggest that css variables (and company) aren't really the way forward, question is how relevant these principles still are today. As for the backwards compatibility I'm sure it's safe to say we better not touch that, but is it really feasible to keep css as simple as possible? I wonder.
simplicity and professionalim
Making css a simple, easy to use language was once a very smart and crucial choice. In the early days people coming from all different kinds of backgrounds could put their stuff online, authoring the design of their site themselves. It really gave the web the boost in needed, with amateurs everywhere publishing and posting their knowledge online. We've come a long way since then though and the web has changed a great deal.
Simplicity also brought many freeloaders and slackers to our profession. Since css isn't very hard to pick and everyone and his dog needed a site to represent themselves online, it was easy to call yourself a web developer and get started right away, asking terrifying sums of money for abominable jobs. It's the reason why the current web is in such a lamentable state, void of usable semantics, inflexible as hell and continuously falling apart when new browsers come along.
Where the introduction of css variables will lead us is hard to predict. Either people with insufficient skills will drop out and we can grow as a profession, or we'll just mess up the web even more. Without a set of well-considered best practices the addition of css variables will lead us to an almost mythical mess. Problem is that like most front-end related problems, there is not one single solution and nobody ever seems to agree on one single best practice (think css notations, use of paddings vs margins etc etc). So we'll just make things harder on ourselves.
other brainbits
I can see some good use for the mixins myself, though at the same time there are many situations where they will prove inefficient rather than beneficial. If you change the original declaration halfway through a project it will be pretty difficult to predict the consequences on the existing css. It will become even worse when using mixins within mixins. And what if for some reason only half the current selectors using a specific mixin need to be adapted.
The same goes for variables. What if you've assigned a blue color value to the variable main-blue, but somewhere in the next phase of the project this color needs be changed to red instead? Do you change the variable name too, or do you make sure that your variable names don't reference their styles. A valid option, but this will definitely put a strain on readability of your own code.
As for nestings, I just don't find this type of css very readable. Maybe it's nice for people writing css property/line css, but I prefer to see my dom tree represented in my css files. Something that a good css editor should be able to fix no doubt, but I can see this kind of css notation turning into a horrible mess within mere minutes of development.
conclusions
I'm not really against these propositions. I believe that within the right context and used by capable people, these additions will make our css cleaner, easier to maintain and more flexible altogether. But the chance of that happening seems rather slim compared to the various ways people can fuck up a css file using variables, mixins and nestings. And considering the state our profession is in, this seems rather likely. I for one do not look forward to taking over such a project.
Maybe I should dive into LESS and SASS to work with these improvements first-hand. That said these new additions will be much harder to adopt on a global scale, compared to current css3 additions. Unless every single (popular) browser out there supports them they are virtually unusable as they will completely fail to render in current browser versions, effectively breaking entire designs of a site. I guess that gives us plenty of time to make up our minds, leading me to believe there's no real reason to stop the current development.
For now, I'll just leave you with the above remarks. No doubt more about this in the future.