An interesting proposal for defining how one element could be “anchored” to another, and how that positioning could be expressed declaratively instead of having to write a whole load of JavaScript. Melanie’s looking for use cases so share ‘em if you have ‘em.
Personally, I’m not convinced that a new element is needed but I’m open to the suggestion.
This is my new favourite indie web site (super performant and responsive too).
Until there is movement on developers taking CSS more seriously and understanding its full capabilities, we are caught in an awkward loop where introducing too much complexity in your project’s CSS will do more harm than good.
CSS-in-JS can have a noticeable impact on your webpage. Mainly for low-end devices and regions with a slower internet connection or more expensive data. So maybe we should think better about what and how we use our tooling. Great developer experience shouldn’t come at the expense of the user experience.
Eric looks back on 25 years of CSS and remarks on how our hacks and workarounds have fallen away over time, thank goodness.
But this isn’t just a message of nostalgia about how much harder things were back in my day. Eric also shows how CSS very nearly didn’t make it. I’m not exaggerating when I say that Todd Fahrner and Tantek Çelik saved the day. If Tantek hadn’t implemented doctype switching, there’s no way that CSS would’ve been viable.
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.
In a break with Betteridge’s law, I think the answer here is “yes.”
This is a great (free!) course on learning CSS from the basics up. Nicely-pitched explanations with plenty of examples.
The point of this post is to show how nicely container queries can play with web components, but I want to also point out how nice the design of the web component is here: instead of just using an empty custom element, Max uses progressive enhancement to elevate the markup within the custom element.
This would be such a great addition to CSS—a parent/ancestor selector!
With the combined might of :has(), :not(), nth-child(), and calc(), CSS has become a powerful language for specifying rules to account for all kinds of situations.
The more I consume content in reading apps, the more I am reminded of the importance and the power of progressive enhancement as a strategy to create resilient and malleable experiences that work for everyone, regardless of how they choose to consume our content.
Top stuff from Sara here!
We have a tendency to always make an assumption about how our readers are reading our content—probably in the browser, with our fancy styles applied to it. But if we make a habit out of thinking about the Web in layers and CSS as an enhancement on top of the content layer, then we can start optimizing and enhancing our users’ reading experiences regardless of their context.
Thinking about the different ways in which users access the Web only shines light on the importance of a progressively enhanced approach to building for the Web. The more we think about the Web in layers and try to improve the experience of one layer before moving to the next, the more resilient experiences we can create. That’s what the essence of progressive enhancement is about.
Using progressive enhancement means your users will be able to do what they need to do if any part of the stack fails.
What a terrific short guide to sensible web development!
- Start with HTML
- Using interactive elements
- Adding the extras
- Building more complex services
- Testing your service
- Do not assume users turn off CSS or JavaScript
- Case studies and related guides
Collection of common CSS mistakes, and how to fix them.
I like the way this is organised: it’s like “code smells” for CSS. Some of them will probably be familiar, in which case, you can dive in and find out what’s going on.
Professional web designer on a closed course. Do not attempt.
I really like the idea of a shared convention for styling web components with custom properties—feels like BEM meets microformats.
Good to see Google, Mozilla, and Apple collaborating on fixing cross-browser CSS compatability issues:
You can track progress here.
Oh, this is smart! You can’t target pseudo-elements in JavaScript, but you can use custom properties as a proxy instead.
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.