Well, now I’m really glad I wrote that post about logical properties!
We’re not there yet. So how do we get there?
Well, I don’t know for sure – but articles like this are very helpful as we try to work it out!
Dave rounds up some of the acronymtastic ways of scoping your CSS now that we’ve got a whole new toolkit at our disposal.
If your goal is to reduce specificity, new native CSS tools make reducing specificity a lot easier. You can author your CSS with near-zero specificity and even control the order in which your rules cascade.
A terrific tour of just some of the fantastic ways you can use :has() in CSS.
The section on using it with sibling selectors blew my mind:
How often have you wanted to adjust the margins on a headline based on the element following it? Now it’s easy. This code allows us to select any h2 with a p immediately after it.
h2:has(+ p) { margin-bottom: 0; }Amazing.
Prompted by my recent post about using native button elements, Trys puts forward a simple explanation for why someone would choose to use a div instead.
The one common feature between every codebase I’ve encountered on that doesn’t use
buttons well, is a bad CSS reset. Developers try to use abutton, and find that it still looks like a native browser button, so they grab a plain old, blank canvasdiv, and build from there.
Occam’s Razor makes Trys’s explanation the most likely one.
I love these notes on my recent talk!
Here’s the video of my opening talk at this year’s CSS Day, which I thoroughly enjoyed!
It’s an exciting time for CSS! It feels like new features are being added every day. And yet, through it all, CSS has managed to remain an accessible language for anyone making websites. Is this an inevitable part of the design of CSS? Or has CSS been formed by chance? Let’s take a look at the history—and some alternative histories—of the World Wide Web to better understand where we are today. And then, let’s cast our gaze to the future!
A really deep dive into flexbox. This is a great example of what I categorise as “thinking like a browser” (a skill I recommend for any front-end developer).
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 is a great tutorial—I just love the interactive parts that really help make things click.
This detailed proposal from Miriam for scoping CSS is well worth reading—it makes a lot of sense to me.
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.
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.”
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.
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.
I really like the idea of a shared convention for styling web components with custom properties—feels like BEM meets microformats.
Oh, this is smart! You can’t target pseudo-elements in JavaScript, but you can use custom properties as a proxy instead.