This is a really in-depth explanation from Bramus of the upcoming @layer rules in CSS, from the brilliant minds of Miriam, fantasai and Tab.
Basically, you’ll be able to scope styles, and you get to define the context for that scoping. So all those CSS-in-JS folks who don’t appreciate the cascade will have a mechanism to get encapsulated styles.
I can see this being very handy for big complex codebases with lots of people on the team.
This detailed proposal from Miriam for scoping CSS is well worth reading—it makes a lot of sense to me.
This is supposed to be a defence of utility classes …but it’s actually a great explanation of why classes in general are a great mechanism for styling.
I don’t think anyone has ever seriously suggested using inline styles—the actual disagreement is about how ludicrously rigid and wasteful the class names dictated by something like Tailwind are. When people criticise those classes they aren’t advocating for inline styles—they’re advocating for better class names and making more use of the power of the class selector in CSS, not less.
Anyway, if you removed every instance of the word “utility” from this article, it would still work.
Given the widespread browser support for prefers-reduced-motion now, this approach makes a lot of sense.
Type and space are linked, so if you’re going to have a fluid type calculator, it makes sense to have a fluid space calculator too. More great work from Trys and James!
Robin makes a good point here about using dark mode thinking as a way to uncover any assumptions you might have unwittingly baked into your design:
Given its recent popularity, you might believe dark mode is a fad. But from a design perspective, dark mode is exceptionally useful. That’s because a big part of design is about building relationships between colors. And so implementing dark mode essentially forced everyone on the team to think long, hard, and consistently about our front-end design components. In short, dark mode helped our design system not only look good, but make sense.
So even if you don’t actually implement dark mode, acting as though it’s there will give you a solid base to build in.
I did something similar with the back end of Huffduffer and The Session—from day one, I built them as though the interface would be available in multiple languages. I never implemented multi-language support, but just the awareness of it saved me from baking in any shortcuts or assumptions, and enforced a good model/view/controller separation.
For most front-end codebases, the design of your color system shows you where your radioactive styles are. It shows you how things are tied together, and what depends on what.
A minimal style sheet that applies some simple rules to HTML elements so you can take a regular web page and drop in this CSS to spruce it up a bit.
A handy tool for getting an overview of your site’s CSS:
CSS Stats provides analytics and visualizations for your stylesheets. This information can be used to improve consistency in your design, track performance of your app, and diagnose complex areas before it snowballs out of control.
The “Adjust CSS” slider on this delightful homepage is an effective (and cute) illustration of progressive enhancement in action.
This is a great talk by Hidde, looking at the history and evolution of cascading style sheets. Right up my alley!
Notes on the old internet, its design and frontend.
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.
Well, this is a fun bit of CSS. Instantly transform a web page into a blast from the past (1998, to be precise).
This is the transcript of a brilliant presentation by Scott—read the whole thing! It starts with a much-needed history lesson that gets to where we are now with the dismal state of performance on the web, and then gives a whole truckload of handy tips and tricks for improving performance when it comes to styles, scripts, images, fonts, and just about everything on the front end.
Essential!
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!
Six steps that everyone can do to catch accessibility gotchas:
- Check image descriptions
- Disable all styles
- Validate HTML
- Check the document outline
- Grayscale mode
- Use the keyboard
A deep dive info focus styles with this conclusion:
The default focus ring works. There are problems with it, but it can be good enough, especially if you can’t dedicate time and energy to create a custom focus ring.
Some very smart ideas in here for resetting default browser styles, like only resetting lists that have classes applied to them:
ul[class],
ol[class] {
padding: 0;
}
I select only lists that do have a
classattribute because if a plain ol’<ul>or<ol>gets used, I want it to look like a list. A lot of resets, including my previous ones, aggressively remove that.
What you see really is what you get. I like this style!
This is such a great excercise for teaching the separation of structure and presentation—I could imagine using something like this at Codebar.