An excellent and clear explanation of specificity in CSS.
Good point. When we talk about perceived performance, the perception in question is almost always visual. We should think more inclusively than that.
I count at least three clever CSS techniques I didn’t know about.
I linked to the first of Ethan’s short videos on accessibility last week, but it’s well worth checking out all five:
A useful resource for CSS grid. It’s basically the spec annoted with interactive examples.
A score of 100 in Lighthouse or 0 errors in axe doesn’t mean that you’re done, it means that you’re ready to start manual testing and testing with real users, if possible.
This is a very nifty use of CSS gradients!
This is a great short introduction to using VoiceOver with Safari by the one and only Ethan Marcotte.
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.
A really great one-page guide to HTML from Bruce. I like his performance-focused intro:
If your site is based on good HTML, it will load fast. Browsers incrementally render HTML—that is, they will display a partially downloaded web page to the user while the browser awaits the remaining files from the server.
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 really, really like Andy’s approach here:
The focus of the methodology is utilising the power of CSS and the web platform as a whole, with some added controls and structures that help to keep things a bit more maintainable and predictable. The end-goal is shipping as little CSS as possible—leaning heavily into progressive enhancement and modern techniques.
If you use the cascade for everything, you’re going to run into trouble. But equally, micro-managing styles on every element will also get you into trouble. I think Andy’s found a really great sweet spot here that gets the balance just right.
CUBE CSS in essence, is a progressive enhancement approach, vs a fight against the grain of CSS or a pixel-pushing your project to within an inch of its life approach.
Yes! It feels very “webby” to me.
Chris has put together one of his indispensable deep dives, this time into responsive images. I can see myself referring back to this when I need to be reminded of the syntax of
…for old CSS problems.
input type="range" and then figure out the CSS you need (which, alas, involves lots of vendor prefixes).
Progressive disclosure interface patterns categorised and evaluated:
- mouseover popups (just say no!),
- new pages,
- scrolling sideways.
I really like the hypertext history invoked in this article.
The piece finishes with a great note on the MacNamara fallacy:
Everyone thinks metrics let us measure results. But, actually, they don’t. They measure only what they are measuring. Engagement, for example, is not something that can be measured, so we use an analogue for it. Time on page. Or clicks.
We often end up measuring what is quick, cheap, and easy to measure. Therefore, few organizations regularly conduct usability testing or customer-satisfaction surveys, but lots use analytics.
Even today, organizations often use clicks as a measure of engagement. So, all too often, they design user interfaces to generate clicks, so the system can measure them.