As a developer, time and time again I have reached one of those classic moments of utter frustration: I want technology X to have feature Y so I can accomplish task Z easier, faster, and make everyone happy with the result.
But technology X doesn’t include feature Y, or doesn’t even have support for a feature Y, so task Z requires more resources – more of my time, my energy, my money, my ability to get more things done and improve myself, my company, my client… and the world.
Then, occasionally, after spending what feels like an endless amount of time searching for a solution, or gluing together a hack, or crafting a spectacular process for accomplishing task Z, something awesome happens: Technology X adopts a new development spec, feature Y, that solves all my problems in an instant. Achievement unlocked!
The needs of Feature Y
Before I dive into explanation of the beautiful thing that is CSS Variables, first, some background: CSS was originally conceived to be strictly, and simply, a presentation layer language of a web page.
It was not intended to be a robust programming language — the robust layers were expected to be handled by stronger, beefier server-side languages, such as PHP and ASP.NET, or even pre-compiled C-based code.
As home user’s computers became more affordable and powerful, the web evolved to develop and make use of the extra compute cycles. And browsers evolved to more efficiently perform the tasks imposed on them by the developers of the websites that took advantage of this additional raw power.
As web page designs rely more heavily upon the basic power of CSS, they gradually become files which repeat values, such as color values, in order to maintain a consistent look-and-feel across a site.
CSS pre-processors, such as LESS and SASS, have taken on the task of automating and simplifying the tedious, bug-prone task of enforcing e.g. a color palette which must be correctly duplicated in many different CSS class definitions.
But as any developer knows from experience by now, with additional gluing and hacking and piling-on of features and addition of layers of complexity to a project’s workflow, eventually, the community reaches a point where a new, leaner, simpler process is demanded — if not necessary — in order to un-complicate our lives, increase productivity of time, of resources, and deliver superior products to our clients at a quicker, more competitive rate.
Feature Y: CSS Variables
Finally, the community has converged upon a solution. It’s called CSS Variables, and it’s rapidly going mainstream.
Developers from the web’s major browsers are adopting it at a rapid pace. Mozilla announced its support for CSS Variables in Firefox 31 two years ago. Though, as Firefox is not the market leader (at ~15% global market share, according to StatCounter), the argument in favor of a mass adoption of the CSS Variables approach, as opposed to the SASS/LESS approach, was too difficult to justify. But no longer.
With Google’s decision to introduce CSS Variables support in Chrome 49, its release in February 2016 as the overwhelming market leader in browser share began an inevitable countdown to the time when the vast majority of internet traffic will be conducted through browsers that natively support CSS Variables.
By this summer, one can be confident that more than 62% of web page visits will be from browsers that can handle CSS Variables.
So, what does this mean for designers and developers?
It’s time to learn and realize the awesomeness that CSS Variables brings to our lives.
Embrace the change.
CSS Variables are a structure, applied in CSS files, in a way which should look familiar to those who have used CSS files before. (For those who have used PHP: you are familiar with the idea of mixing PHP code alongside basic HTML/CSS inside the same file.
CSS Variables follows a similar concept, acting as an optional feature to be used amongst “regular” CSS statements.) They allow developers to define reusable property variables in CSS without relying upon external hacks (e.g. SASS “variables”). Developers can then use the var() function to reference their custom properties anywhere in the CSS document.
You can read Google’s official statement about this powerful feature (which they refer to as “CSS custom properties”) on their Google Chrome Releases blog post.
In a short amount of time, Opera’s browser, being a downstream branch of Chromium, will have incorporated support for CSS Variables as well.
Microsoft is already gearing up their Edge browser for eventual support, as they’ve announced its under consideration at Redmond. The lone holdout for now, Apple’s Safari, will inevitably adopt support along with the rest, thus bringing CSS Variables support to practically the entire Internet. All within the next several months!
So… what about Sass and LESS? :/
Native browser support for CSS Variables won’t dethrone Sass and LESS. They are still very powerful pre-processors. The CSS Variables feature is just that — about variables for CSS declarations — and don’t include support for other awesome features, like mixins.
So there will still be a legitimately cool use for the CSS superchargers — the higher-order uses that share more in common with the unique capabilities of server-side programming languages: functions and other complex reusable components. Just that now we can simplify our workflow by using CSS-based variables where they truly belong: natively, on the browser level.
Simpler, faster, more efficient, and at the end of the day, everyone is happier.
If you’re looking for someone to build an app for you or if you have questions, contact our team at Concepta and we’ll be able to help.