Friends! Patrons! E-lurkers!

This week: some updates to the blog and some ranting thoughts about 11ty.

Last night I made some improvements to the visual design. I’m still not entirely happy with it—yet!—so it’s likely to go through a thousand revisions until I’ve dialed it in. I wasn’t happy with my personal blog for about a decade until I hit the sweet spot so I’m in no rush here.

I’ve also added tags to each post now so you can quickly look up related posts on a given topic which should become more handy in the future as the archive builds up. At some point I want to go spelunking back through all my mistakes and the lessons I learned about one aspect of CSS, say colors for example, and see my thoughts change over time.

Friends! Browser bugs! Sentient DOM nodes and key-value pairs!

It’s Robin here and you might notice a few unfamiliar things with this newsletter. Well, it’s been a couple of weeks since the last entry too but there’s a good reason for all these changes I promise. In fact, I come bearing great news through the wires, over the mountains, and across the seven seas: I made a good ol’ fashioned blog for The Cascade!

Behold: https://csscade.com

Making a new blog in 2024 about front-end development might seem a little daft at first though. Haven’t we all moved onto Discord or some enormous 30,000 person Slack channel by now? Aren’t we transcribing our thoughts directly into clouds in the sky and reading our most private thoughts through interfaces that are projected onto our hands already?

When someone makes a website for the first time they’ll have to wrap their head around this:

• HTML is for meaning
• CSS is for presentation
• JavaScript is for interaction

The lines are clearly drawn at the beginning but any web developer knows that this isn’t really the case. You can really mess up the meaning of a HTML document with CSS for example, but I especially disagree with that last bit. Doesn’t a <form> element imply some kind of behavior? Doesn’t it give you interactions outta the box — submit, etc.?

Okay that all sounds like a big philosophical nothing, picking at each word like a total jerk, but I think this stuff structures how we understand the web and what we build on top of it. Once we teach ourselves that interactions solely live within the domain of JavaScript then we stop to question it. We stop to think deeply about how all these languages should overlap with one another.

I love the <style> tag and I love CSS. I still think the way that styles cascade and can’t error out is ingeniously resilient. But, in this blogger’s opinion, the cascade has always had this glaring, terrible flaw.

Let me explain: many years ago, I decided to avoid creating any more CSS files. These projects are admittedly very small but as soon you go down the path of creating a bunch of CSS files you then end up creating dozens more until you’re spending the majority of your time thinking about this enormous system of files you’ve created instead of the interface you’re trying to build. You’re then encouraged to add a fragile build system to compile all these CSS files together—and whenever I returned to a project after a few years I’d find that everything would break because of some update. Then, to be a good performance boy, you really ought to minify all those files into your HTML and sweet heck all I wanted to do was style a <p> tag!

Instead, there is nothing more blissful, simple, and humble as combining CSS and HTML together, like this:

<my-component>
  <style>
    p {
      background: red;
    }
  </style>
  <p>This text is now red.</p>
</my-component>

Pals! Friends! Future Acquaintances Whomst I Shall Inevitably Disappoint!

Last week I was working on the new introduction to my website and I was having a blast. It’s a mini-manifesto in the style of HyperCard that describes what I hope to do with my career and my website. Look at all those illustrations and icons! I found an archive of things that came bundled with macOS—before Jobs shuttered the HyperCard project—and I had a whole lot of fun tweaking and editing them into something that feels familiar but new:

The page is a big carousel where you can click forwards and backgrounds through cards but as I was building it I realized something truly dreadful: how does background work again in CSS? I know that I can stretch that cool, marbled texture to fit the page but what’s the right value I need to do that again?

Friends! Colleagues! Patrons of this fine newsletter! I saw a post today that hit me like a ton of bricks. But first, some context.

Many moons ago I was experimenting with blend modes in CSS, working on a hacky demo where the text color of an element would adapt to its background. This could be handy in all sorts of situations like design systems or allowing folks to create their own themes on a website, but I was focused on this one loading state pattern I’ve seen in the past.

It’s a button that, once you click it, you can see the progress visually as a solid color fills in the background and the text color responds in kind:

Pals! Comrades!

This week I have two links that pair well together. First, here’s Stephanie Eckles’s excellent post about 12 modern CSS upgrades where I just learned about the outline-offset property, which I had no idea existed at all:

.element {
  outline: 2px dashed blue;
  outline-offset: 0.5em;
}

This lets us effectively add padding around an element and move the outline which is often why I stopped using outlines altogether and chose borders —controlling them with CSS was either too annoying or sometimes impossible. So this is great and might help us make more aesthetically pleasing :focus states.

Yesterday I got coffee with a pal who I used to work with on a design systems team that no longer exists. And, as we were talking, we both realized that everyone we worked with no longer even does design systems work these days. They might still be interested in the subject, might still write about it, but they no longer actively work on a team that’s dedicated to design systems.

That’s weird! Why is that?

My pal mentioned that it’s just exhausting: design systems work isn’t like regular front-end development where you have a problem, a business objective or goal and then you go out and build something to fix it. When it comes to front-end development—or activities that now seem to fall under the umbrella of “design engineer”—you don’t have to explain why that work is worth doing: I make you money, the design engineer can argue, because your website has value for your business and I fix these problems.

But when it comes to design systems work you often have to explain to folks why your job is worth doing in the first place. As a product designer or engineer you might have to argue for a feature or even fight for the existence of a team if you’re unlucky, but you rarely have to deal with the existential threat that your whole career shouldn’t exist.

Friends!

Stardate: 2015. Month: September.

I was stood in line for coffee in Portland and if you looked closely enough then you’d notice my gentle swaying from side to side because I was struggling: the city was an open oven — I was wearing shorts (my sincerest apologies) — and my hangover was all-encompassing, overwhelming, intergalactic. I was also coming apart at the seams from anxiety and hoping that no-one in the crowd would spot me. Just let me be invisible, I thought to myself as I stood in line. I just want to quietly watch all these amazing talks at this conference from a safe distance and then crawl back to my hotel room where I can go back to making websites in the dark.

But up until this point I’d never hung out with folks who love websites and, well, that’s why everyone was here! They’d come from all over the country to talk about the web and art and how those things fit together. Surely the person standing behind me in line wasn’t going to hit me with an axe and was more likely than not to be obnoxiously talented and interesting. So I turned on my heel and the guy behind me gave a warm, welcoming smile so all that worry of mine evaporated in an instant.

E-pals!

One of my favorite things about the web is how the addition of a tiny and almost insignificant new property can delete hundreds of lines of extraneous code that we’ve had to write for a decade or more. I strongly believe that replacing a whole bunch of CSS with a single line of HTML is more comforting than taking a long hot bath on a mountain top.

i.

Here, let me prepare your bath this morning:

i.

Despite being famous around the world as a “CSS entrepreneur” and being “extremely annoying about fonts” I must admit to a mistake here and there. Like this week where I was reading CSSmas 2023, Sarah Gebauer’s excellent series of blog posts, and I discovered a worrying initial-letter shaped hole in my CSS databanks.

What the heck is this thing? Let’s take a look:

p:first-of-type:first-letter {
  initial-letter: 3;
}

Two quick things this week. First, my favorite CSS trick I’ve seen in a while followed by even more thoughts about web components.

(I am sorry that I have become a total shill for Big Web Component).

i.

My favorite snippet of the week is courtesy of David Darnes who has a neat idea: a tiny scroll to top link that reveals itself as you scroll, but does so with the following CSS...

This weekend is a quick one with just five things to read since I’m still recovering from all the pies and baked goods of Thanksgiving. The brisk and biting cold air has returned to San Francisco and so I’m writing this from a cafe whilst bundled in the biggest sweater you can possibly imagine. It is glorious. I am happy.

Okay, onwards! Let’s get this show on the road.

i.

Josh Comeau’s interactive guide to CSS Grid is so good that it hurts. I simply wish I had a resource like this when I was learning Grid years ago! The demos are especially good in this post and really help parse the somewhat intimidating language of properties like grid-template-columns and what not.

First a quick note, then some excellent feedback from readers.

Then, finally, the future.

i.

This week I spotted a great reminder from Michelle Barker about how CSS nesting is widely available:

Friends!

Last week I rambled out loud about web components and how their true magic lies in extending HTML. Heck, Jeremy even called them “HTML web components” in a blog post which feels like the perfect framing for them.

You might have noticed how I’ve written several hundred words about the subject already and have not once mentioned Shadow DOM, slots, or templates. And that’s because before we get to styling our web components or making anything more complicated we have to sloooowly build up to all that stuff. Otherwise we’re bound to repeat what happened to me when I started learning about the styles of web components before I understood the philosophy behind it all.

Thus ensued a mid-life crisis that I'd rather not talk about.

Friends!

I’m a few days late with this edition so let’s jump straight in.

i.

Sometimes text can look weird and, depending on how many lines and the length of the words in a sentence, the text can look unbalanced. Widows and orphans, etc. Thankfully, there’s two handy tools we have for controlling these things in CSS: text-wrap: balance; and text-wrap: pretty;.

Friends!

This week, two things.

i.

It took me a long time to figure out why color-mix() is so neat and why I’d need it as a developer. But it wasn’t until I spotted this demo on MDN where it made a lot more practical sense to me — mixing a splash of white into a color.

Friends!

This weekend I’ve come down with a bad cough/flu so I’m going to keep typing and then stop when I stop. Apologies in advance if this whole thing is more of a surrealist poem than a typical newsletter. Okay, let’s do this!

(cough)

i.

I’ve got a terrible thing to admit. It’s something unforgivable, something so dark and heinous that I’ve waited years to tell you all out of fear of blackmail or just overwhelming, incomprehensible shame. Here it is, and I’m sorry in advance:

I still use hex values, like #FFF, in my CSS.

I know, I know! I should be using hsla() right? Or...uhhhh...lch()? Wait, no, I got this, I got this. It’s lab()! Or...hwb()? Of course. Duh! I should be using oklab()! That’s the best of the best and the future for color in CSS. I’m 100% confident here. WAIT! I’m supposed to be using color() instead now? But that’s a Safari-only thing, right? Huh? Wah?

Joking aside, I knew that hsla would be faster for tweaking colors than picking a random hex value but, and I note: I am stubborn as hell. Plus, now in 2023, CSS can do so many new and weird things with color that it’s pretty overwhelming and it’s far easier to simply put a hex-colored blanket over my head and pretend that nothing has changed since I started writing CSS back in 2012.

Friends!

Welcome to The Cascade, a newsletter about the past, present, and future of CSS. I’m your host, Robin Rendle, and to kick things off we’re gonna talk about what scares me most about CSS in 2023.

Lots of newish things in CSS mostly are mostly cool and not scary at all. Take nesting for instance, now available in Safari Technology Preview, where soon enough we’ll be able to write CSS like this:

ul {
    padding: 2rem 1rem;

    li {
        margin-bottom: 1rem;
    }
}