css Audio - Active file-generic CSS - Active Generic - Active HTML - Active JS - Active SVG - Active Text - Active file-generic Video - Active header Love html icon-new-collection icon-person icon-team numbered-list123 pop-out spinner split-screen star tv
CodePen probably won't work great in this browser. We generally only support the major desktop browsers like Chrome, Firefox, Safari, and Edge. Use this one at your own risk! If you're looking to test things, try looking at Pens/Projects in Debug View.
user profile image

I've seen a few examples recently of CSS variables and I thought I'd do a quick demo of some good and bad ways to use them.

This is more for education that wow and kind of a blog post in code comments. Sorry for that!

Comments

  1. This is a perfect example of the advantages of CSS variables. My first try was to set up a 'number of slides visible' variable for a gallery. Change just one variable and all of the previous CSS accommodates for the single changes. Lovely!

  2. What if you did this?

    :root {
        --font-scale: 1.2;
        --font-size-1: 1rem;     
        --font-size-2: calc(var(--font-scale) * var(--font-size-1)); 
        --font-size-3: calc(var(--font-scale) * var(--font-size-2));
        --font-size-4: calc(var(--font-scale) * var(--font-size-3));
        --font-size-5: calc(var(--font-scale) * var(--font-size-4));
        --font-size-6: calc(var(--font-scale) * var(--font-size-5));
    }
    
    
    @media screen and (min-width: 800px) {
        :root {
    
                   --font-scale: 1.33;
             }
    }
    
  3. Spot on man, I thought exactly the same thing. Keep the size and scale in variables and there isnt a need to repeat the individual declarations inside the media query!

  4. @goldnate You could do that. I do like that it is just the scale number that needs to change. But it's not really the point of the demo to show the best\shortest way to calculate a modular scale. I picked modular scales as a somewhat arbitrary example.

    That aside I'd probably still steer away from something like that. It's clever but it's not hard to write out 6 numbers and I think it's useful to see what the actual font-size for each variable is. On top of that designs change and you may want to deviate away from a perfect mathematical scale. In the end it's probably about the same amount of characters to type.

    This is heading towards building a theme system where you change a few key variables and it results in dramatic changes to the deigns. I've always thought this was not a good idea even in Sass. It might be a good if you are sure you are creating a solid reusable abstraction. But in reality I've never successfully reused code like this.

    But developers love clever abstractions ;)

  5. @MadeByMike, Responding to your response to @goldnate — I'm not sure your CSS Variable suggestion (a very good example of a feature of Custom Properties! 👏🏻 This is a great pen!) is significantly less of a clever abstraction. It does not add additional functionality to the CSS (apart from opening these heading values up for editing later in the CSS), and a potential negative is that if the :root media query re-declaration is not seen by the developer looking at the h1, h2, h3, etc. selectors, it may not be immediately clear that those values will be changing at some point. From my still-waking-up-in-the-morning, armchair-hot-take point of view, this seems like an abstraction. The logic you applied against Nathan's suggestion should be equally applied against the Custom Properties concept.

    This is not a considered, hard-and-fast stance I have, just some thinking-out-loud, trying to encourage seeing this from a different perspective.

    Personally, since I have high ownership of our company's CSS efforts, and encounter significant reuse of my boilerplate code, Nathan's suggestion wins the day for me*. Type scales are often arbitrarily chosen, and I've spent enough time doing the math and typing them out that abstracting this to a flexible variable makes a lot of sense — for me. I recognize that my perspective is particular and mileage may vary.

    * At the end of the day, my clients can't yet afford to support the usage of Custom Properties. 😂 I'm favoriting your excellent pen for reference as I learn more about Custom Properties and consider the possibilities. Thanks for making this and listening.

  6. @kbav Sorry I missed your response. Better late than never I guess. Thanks for sharing.

    I'll point to this as my reasoning for writing out the type scale in a visible way rather than computing them on the fly: https://medium.freecodecamp.org/dont-do-it-at-runtime-do-it-at-design-time-c4f59d1775e4 - Says it better than I could in comments ;)

    Regarding " it may not be immediately clear that those values will be changing at some point." I've always found it hard to tell what is changing. My reason for moving variable declarations to the top is so that it is clearer what CSS properties change. I detailed this here: https://www.madebymike.com.au/writing/using-css-variables/ - Does that make sense? It's been a huge win for me.

    If you are building a customisable UI library like bootstrap or something, sure having a --font-scale variable might make sense or for theming. But I'm not sure it does in many other situations or for most typical websites.

    Of course, likewise, this is my experience and mileage may vary.

Leave a Comment Markdown supported. Click @usernames to add to comment.

You must be logged in to comment.
Loading...
Loading...