It’s been a while since I’ve heard anything about CSS Variables and it adds a whole new toolset and way of thinking to front end development that excites me.
A Refresher on CSS Variables
CSS Variables have been knocking around for a few years now but don’t seem to be in wide usage. With the popularity of pre-processors such as Sass, frontend developers scratched that variable itch a long time ago.
I was first excited by CSS Variables in around 2014 and since then they’ve dipped in and out of my interest sphere. I’m only now considering getting them into production sites and I’m going to show you how simple and easy they are to use.
Declaring the Variable
Declaring the custom property is simple: We need only create the property we want and append two dashes to the beginning of it. These can be declared anywhere but adding them to :root seems to be a good approach at the moment.
--my-reusable-value: 20px;
Accessing the Variable
Using the property is pretty simple as well. We access it through the var() function and use the property we declared above.
padding: var(—my-reusable-value);
Isn’t that simple and glorious?
CSS Variables are straightforward to use and pretty easy to remember. The biggest challenge with CSS Variables (as with most CSS) is knowing the right time and place to use them. Throwing them in haphazardly is a sure fire way to create a mess of a stylesheet and with these variables thrown in debugging will probably become more difficult.
Proper use cases and strategies for using them should be considered and this is where the majority of your effort should be focused.
An Interesting Use Case : Responsive Modules
In the following example I’m going to show you a basic example of how I currently build a responsive component using Sass variables. Then I will show you how it could be improved upon with CSS Variables in a way that’s not possible with a pre-processor. This is a specific use case which does not apply to every way variables are used but is to show how CSS Variables can be used differently.
Sass Example
See the Pen CSS Variables – responsive use case without CSS Variables by Adam Hughes (@lostmybrain) on CodePen.
When using Sass there are a few different methodologies I’ve tried. My current go to version is placing media queries within the CSS blocks I want to change. In here I can use a variable, standard CSS, mixin or an extend to modify this element without scattering the styles for the component everywhere.
One problem with this is having multiple media queries and lots of variables which are kind of related but not. I could use maps for the variables which would give more organisation but I think the main issue is that we’re using a multiple variables to define one property. This just feels wrong.
Sass variables are used ahead of time which means we have to plan every way we’re going to use them. They make developing easier but technically don’t provide us with any new superpowers.
CSS Variables to the Rescue
See the Pen CSS Variables – responsive use case by Adam Hughes (@lostmybrain) on CodePen.
CSS Variables do not need to be declared up front, they are dynamic. This is useful in a very different way. We can now conditionally change variables from anywhere and in specific contexts such as media queries.
By serving our media query styles right up from we can reduce the amount of media queries scattered around for responsive styling. It also gives a really nice and clean way to see general spacing and typography styling across different formats.
I think responsive designs and theming are two excellent use cases for CSS Variables but there are so many possibilities.
How Are CSS Variables Different From SASS Variables?
Sass Variables and CSS Variables are two different beasts, each with their own pro’s and con’s.
Sass Variables Can Be Organised Better
Due to the popularity of Sass and the more programmatical nature of Sass, more in depth organisation patterns have evolved over time. I particularly like sass maps and combining similar type variables into the maps. Colors, sizes and shortcuts for paths seem to be popular choices for including in maps.
Because of the relatively smaller usage of CSS Variables the best practices have yet to evolve. Maps and arrays are not possible in the same way in CSS so these new organisational patterns will have to innovative and solve the problems in a different way to Sass.
CSS Variables Can Be Dynamically Changed
CSS Variables are handled dynamically by the browser at runtime whereas Sass Variables are used when the CSS is compiled.
This is the core selling point of CSS Variables for me. It will be interesting to see how people use this feature over time and whether it will live up to its potential.
CSS Variables Are a Standard Browser Feature
I’m personally of the opinion that the more things we can remove from Webpack, Gulp, and whatever-new-framework-is-out-now, the better. Having interesting new browser features means we don’t have to rely on compilation and JavaScript frameworks to do things developers feel are essential. I would hazard a guess that a high percentage of frontend developers use variables in their CSS in one way or another, so everyone using this a core feature seems like a sensible thing to do. It means one less thing in the build step (which I think we can all agree is getting pretty immense these days) and more consistency across the web.
What Is The Support Looking Like?
The support is looking remarkable good with one glaring exception: IE 11. Most modern browsers support CSS Variables with Edge having a few bugs.
At 78.11% this is higher than CSS Grid (at the time of writing) but that IE11 support could be a problem.
So, Can We Use CSS Variables Yet?
I think the time is now. That IE11 support is not going to get any better, and we know from previous versions of Windows that it takes a long time for some people to upgrade. But the support across modern browsers is great which means we should be looking to CSS Variables and experimenting with the possibilities.
That doesn’t mean we shouldn’t forget about our responsibility to older browser support though. A basic fallback system using a supports tag, or even a polyfill, for older browsers should be considered, even more so if your actual site usage is a lot more skewed to older browsers.
It’s an exciting time for front end development, and I for one can’t wait to be using more of these technologies in my production sites.
| 115+ Vintage Logo Templates & Photo Mockups – only $16! |  |
p img {display:inline-block; margin-right:10px;}
.alignleft {float:left;}
p.showcase {clear:both;}
body#browserfriendly p, body#podcast p, div#emailbody p{margin:0;}
from Webdesigner Depot http://ift.tt/2kXWOZq
from WordPress http://ift.tt/2yxzve6
No comments:
Post a Comment