? The Cascade ??

[Robin]: This week I happened to be to re-reading a post from Chris that I think is some of the best advice for writing CSS out there. It captures strategies for keeping CSS specificity low:

Keeping CSS specificity low across all the selectors in your project is a worthy goal. It’s generally a sign that things are in relative harmony. You aren’t fighting against yourself and you have plenty of room to override styles when you need to. Specificity on selectors tends to creep up over time, and there is a hard ceiling to that. I’m sure we’ve all felt the pain of !important tags and inline styles.

One of the bits of advice that I really like is called “use the cascade” and in it Chris encourages us to just let our solid base of styles do all the heavy lifting for us. The idea is that if we have a good foundation then everything else will be easy.

[Chris]: That post is 5 years old, but I still essentially work that way, and did the 5 years leading up to that post as well. My projects are generally of rather medium scale, so keep that in mind. My CSS methodology is “Use some nice default global styles. Use a class for the main thing you’re styling (and variations). A little tag nesting in that class is OK, otherwise, it feels like you’re over-naming things. If an instance of nesting becomes an issue, flatten out into classes.”

Miriam has another take on things that I also think is interesting.

We really can use a full range of selectors:

• Element types for global defaults
• Classes/attrs for reusable patterns & components
• IDs for truly one-off layout elements

(Reasonably) Nested selectors are also ok. CSS was designed to work that way.

I actually think the main cascade limitation is too few layers of origin/specificity – not too many. Flat (single-class-for-everything) selector conventions cause more problems:

• Only a single (cluttered) .classname space
• Source order is everything, and that’s dangerous…

[Back to Robin]: This had me thinking though: whenever folks talk about the cascade they often mean CSS specifically and how one selector can override another—but!—when it comes to web design I think there’s another cascade that we should talk a bit more about.

All web design decisions should follow what I have started referring to as The Other Cascade™️. It’s a decision-making process for how to build good interfaces and I’ve found that it helps me tackle a problem in the simplest way possible. Okay, okay—enough bragging—these are the questions I ask myself when tackling a problem:

  1. Can design solve this problem?
  2. If not, can HTML solve this problem?
  3. Okay, sure, can CSS solve it then?
  4. No? What about plain ol’ JavaScript?
  5. FINE. Let’s try the framework we currently use.
  6. SURE. WE GET IT. Let’s just npm install whatever. I’M GOING TO BED.

To be honest with most problems I’ve found that our team can design our way out of it. If we make the UI only as complex as it needs to be and no more then we won’t have to write a ton of fragile and goofy code (this is why senior front-end developers say “No, Absolutely Not.”)

What’s an example of design solving technical problems?

Well! We don’t need a responsive images solution if we don’t have images! Do we really need that giant carousel? If we remove it then we can trash all this complex third party code. What can we subtract from the design to reduce complexity? Get that weird thing outta there!

By simplifying the technical issues at the design level we can reduce the complexity of our codebase and increase the consistency of our design. But my point with The Cascade™️ (please follow up with me on all licensing requests thank you very much) is that using a framework or installing a giant library of stuff should be the absolute last thing you reach for. And only once all the other options have failed.


Over on CodePen, Yuan Chuan has made this rather nifty demo which sets type on a circle with each letter and an offset-path:

So offset-path really is more more than just animation! SVG is still probably easiest for text-on-a-path, but this is a heck of a lot easier than old methods we’ve blogged.

The possibilities of this are incredible.


In Going Beyond Automatic SVG Compression With the “use” Element, Mariana Beldi shows us how to do just that by taking the following SVG that was exported from Illustrator:

…and then breaking it up into reusable pieces so that it’s possible to build things in a much more systematic way which could eventually lead to a complex graphic such as this:

Mariana then wrote a follow-up piece about the <use> element—which is how you can make these reusable chunks of SVG code—and then applies that to SVG animations. She then shows us how to use CSS variables to change the styles of those reusable SVG pieces, too.


Jeremy Wagner has written this great piece about how innovation in technology can’t keep the web fast:

It’s becoming increasingly clear that web performance isn’t solely an engineering problem, but a problem of people. This is an unappealing assessment in part because technical solutions are comparably inarguable. Content compression works. Minification works. Tree shaking works. Code splitting works. They’re undeniably effective solutions to what may seem like entirely technical problems.

Jeremy comes to the same difficult conclusion that we all eventually get to I think: bad performance is a cultural problem. We can’t just sit in our offices and make the company website fast—we need to train folks about the technical details but we need to make folks empathize with the problem, too.

Speaking of which, Scott Jehl has a great course about improving web performance that should be of interest, too!


Here’s a great piece by Sarah Soueidan on accessibility, HTML, and how we can go about using ARIA roles:

ARIA attributes are possibly the most powerful tool in our accessibility arsenal. Many ARIA attributes mirror native HTML semantics, while others provide semantics that do not natively exist in HTML. They don’t change behavior or add functionality. They don’t make an element focusable or add keyboard behavior, for example. So if you do choose to go the route of making a button out of a div, you’re gonna have to add that functionality yourself using JavaScript. But why create a brittle implementation of something that is already provided to you by browsers?

I really like the way that ARIA is described in this piece as “a promise” that we have to keep—and how we have to ensure that we’re not making things worse when we use them.

WordPress.com now has SFTP and Database Access

I’m the type of developer who likes to hack on my theme! Me too, dear reader, me too. In the past, that may have been a reason not to choose to put your site on WordPress.com. No more. If you’re on the Business or eCommerce plans, you have direct access to your site’s database (via phpMyAdmin) and files (via SFTP). You can also install plugins, giving you as much control over your WordPress site as you’d likely ever need.

IntersectionOberserver is quite a nice API in that it is an extremely performant way to check elements relative position to the browser window? Is it visible? Is it partially visible? Is it above or below the viewport? I like these demos that use it for something as incredibly practical as on-page table-of-contents active navigation styling.