What Can You Put in a CSS Variable? / Coder’s Block
A reminder that the contens of custom properties don’t have to be valid property values:
From a syntax perspective, CSS variables are “extremely permissive”.
A reminder that the contens of custom properties don’t have to be valid property values:
From a syntax perspective, CSS variables are “extremely permissive”.
A spot-on summary of where we’ve ended up with web components.
Web Components had so much potential to empower HTML to do more, and make web development more accessible to non-programmers and easier for programmers.
But then…
Somewhere along the way, the space got flooded by JS frameworks aficionados, who revel in complex APIs, overengineered build processes and dependency graphs that look like the roots of a banyan tree.
Alas, that’s true. Lea wonders how this can be fixed:
I’m not sure if this is a design issue, or a documentation issue.
I worry that is a cultural issue.
Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because “here is my truckload of dependencies, yeah, what”.
This is a great bit of detective work by Amber! It’s the puzzling case of The Browser Dev Tools and the Missing Computed Values from Custom Properties.
Who do I know working on dev tools for Chrome, Firefox, or Safari that can help Amber find an answer to this mystery?
I think this a solution worthy of Solomon. In this case, the Gordian knot is the select
element and its inevitable recreation in order to style it.
What if we instead deliver a native select by default and replace it with a more aesthetically pleasing one if possible? That’s where the “hybrid” select idea comes into action. It’s “hybrid” because it consists of two selects, showing the appropriate one at the right moment:
- A native select, visible and accessible by default
- A custom select, hidden until it’s safe to be interacted with a mouse
The implementation uses a genius combination of a hover
media query and an adjacent sibling selector in CSS. It has been tested on a number of device/platform/browser combinations but more tests are welcome!
What I love about this solution is that it satisfies the stakeholders insisting on a custom component but doesn’t abandon all the built-in accessibility that you get from native form controls.
Matthias has a good solution for dealing with the behaviour of CSS custom properties I wrote about: first set your custom properties with the fallback and then use feature queries (@supports
) to override those values.
Yet another clever technique from Lea. But I’m also bookmarking this one because of something she points out about custom properties:
The browser doesn’t know if your property value is valid until the variable is resolved, and by then it has already processed the cascade and has thrown away any potential fallbacks.
That explains an issue I was seeing recently! I couldn’t understand why an older browser wasn’t getting the fallback I had declared earlier in the CSS. Turns out that custom properties mess with that expectation.
Sara shares how she programmes with custom properties in CSS. It sounds like her sensible approach aligns quite nicely with Andy’s CUBE CSS methodology.
Oh, and she’s using Fractal to organise her components:
I’ve been using Fractal for a couple of years now. I chose it over other pattern library tools because it fit my needs perfectly — I wanted a tool that was unopinionated and flexible enough to allow me to set up and structure my project the way I wanted to. Fractal fit the description perfectly because it is agnostic as to the way I develop or the tools I use.
I’m not the only one swapping out Sass with CSS for colour functions:
Because of the declarative nature of CSS, you’re never going to get something as terse as what you could get in Sass. So sure, you’re typing more characters. But you know what you’re not doing? Wrangling build plugins and updating dependencies to get Sass to build. What you write gets shipped directly to the browser and works as-is, now and for eternity. It’s hard to say that about your Sass code.
This is clever—using custom properties to enable if/else logic in CSS.
I don’t understand what currying is, but Trys points out a really interesting thing about custom properties in CSS:
The value after the : in the CSS custom property does not have to be valid CSS.
That means you can use custom properties to store arbitrary strings of text, which can then be combined within a calc()
function, at which point they get evaluated.
Andy takes Utopia for a spin—it very much matches his approach.
This is the project that Trys and James have been working on at Clearleft. It’s a way of approaching modular scales in web typography that uses CSS locks and custom properties to fantastic effect.
Utopia is not a product, a plugin, or a framework. It’s a memorable/pretentious word we use to refer to a way of thinking about fluid responsive design.
It’s now easier than ever to style form controls without sacrificing semantics and accessibility:
The reason is that we can finally style the ::before and ::after pseudo-elements on the
<input>
tag itself. This means we can keep and style an<input>
and won’t need any extra elements. Before, we had to rely on the likes of an extra<div>
or<span>
, to pull off a custom design.
The demo is really nice. And best of all, you can wrap all of these CSS enhancements in a feaure query:
Hopefully, you’re seeing how nice it is to create custom form styles these days. It requires less markup, thanks to pseudo-elements that are directly on form inputs. It requires less fancy style switching, thanks to custom properties. And it has pretty darn good browser support, thanks to
@supports
.
Lynn gives a step-by-step walkthrough of the latest amazing redesign of her website. There’s so much joy and craft in here, with real attention to detail—I love it!
A very handy web component from Paul—this works exactly like a regular YouTube embed, but is much more performant.
Heydon cracks me up—his Patterns Day is going to have you crying with laughter; guaranteed!
Here he is talking about custom properties in CSS as part of his Making Future Interfaces video series.
CSS grid and custom properties really are a match made in heaven.
I’ve often said that the goal of a good library should be to make itself redundant. jQuery is the poster child for that, and this article points to web components as the way to standardise what’s already happening in JavaScript frameworks:
Remember when
document.querySelector
first got wide browser support and started to end jQuery’s ubiquity? It finally gave us a way to do natively what jQuery had been providing for years: easy selection of DOM elements. I believe the same is about to happen to frontend frameworks like Angular and React.
The article goes on to give a good technical overview of custom elements, templates, and the Shadow DOM, but I was surprised to see it making reference to the is
syntax for extending existing HTML elements—I’m pretty sure that that is, sadly, dead in the water.
Er …I think Heydon might’ve cracked it. And by “it”, I mean container queries.
This is some seriously clever thinking involving CSS custom properties, calc
, and flexbox. The end result is a component that can respond to its container …and nary a media query in sight!
I think Cathy might’ve buried the lede:
The knock on effect of this was removing media queries. As I moved towards some of the more modern features of CSS the need to target specific screen sizes with unique code was removed.
But on the topic of Sass, layout is now taken care of with CSS grid, variables are taken care of with CSS custom properties, and mixins for typography are taken care of with calc()
.
Personally, I’ve always found the most useful feature of Sass to simply be that you can have lots of separate Sass files that get combined into one CSS file—very handy for component libraries.