#252: Nightmare CSS

[Robin]: Stefánia Péter made a neat website called CSS Hell. It tells us what to avoid when writing CSS and I like this note about specificity:

Developers often write overly specific selectors just to be 10000% sure their rules will rule.

Stefánia then gives this example:

div#my-popup div span.my-radiocheckbox-label-text {
  color: #666;
}

This is the sort of CSS that will lead to nightmares, but how do we fix it? Okay, sure, we can replace it with a single CSS class most likely:

.radio-label {
  color: #666;
}

That’s a good first step but what happens when we find color: #666; a hundred times in our codebase? I’d say that specificity isn’t the problem in this case, but instead it’s the sign of a bigger problem with our system of styles. Is #666 some random color we want our label to be or all our labels?

We can simplify that further:

.label {
  color: #666;
}

Or is #666 the secondary color we use throughout our website? In that case, we should have a variable that we can change to make sweeping changes within our codebase:

:root {
  --c-secondary: #666;
}

.label {
  color: var(--c-secondary);
}

.another-component {
  color: var(--c-secondary);
}

Now, instead of fixing this one CSS problem (which can be annoying), we’re now solving system-level problems throughout our app.

It’s important to remember that specificity is always the sign of a bigger disagreement within a codebase and fixing those disagreements is the way to really make CSS scale across hundreds of components. It’s hard and annoying but it’s how you make sure the developers on your team and working as efficiently as possible and aren’t secretly arguing in your codebase.

Anyway, ranting aside, CSS Hell is riffing of Manuel Matuzović’s excellent HTML Hell that similarly walks through common mistakes and pitfalls when writing HTML.

Here’s Manuel on the problems with close buttons for instance:

In modals, ads, and other overlays you often find a button with a close symbol that allows users, or at least some of them, to close the overlay. This functionality is often limited to mouse users, because most implementations of close buttons suck.

Then Manuel gives us fifty different options for building a better close button for something like a modal and then talks about all those potential problems, too. Reading through all the different methods for this one particular thing reminds me that there’s never one way to build a website. There’s no easy guide for anything because all of these things are so very complex and nuanced.

Front-end development is hard! Who knew.


Learn CSS

Speaking of learning resources, Learn CSS is a new resource for new and experienced CSS-ers alike. Each part of the language is broken up into fantastic guides that have been designed so you can return to them again and again:

You’ll learn CSS fundamentals like the box model, cascade and specificity, flexbox, grid and z-index. And, along with these fundamentals, you’ll learn about functions, color types, gradients, logical properties and inheritance to make you a well-rounded front-end developer, ready to take on any user interface.

Each module is full of interactive demos and self-assessments for you to test your knowledge. In addition to learning through reading and demos, there is an accompanying podcast episode for each topic as another way to learn and continue expanding your knowledge.

After deep diving through the site, I found that I didn’t know much about logical properties in CSS, like this bit of CSS…

.my-element {
  max-inline-size: 150px;
  max-block-size: 100px;
}

/* which is the same as... */
.my-element {
  max-width: 150px;
  max-height: 100px;
}

That looks wild to me. But if you’re building an interface with a left-to-tight writing mode that interface can be changed to read from right to left, then logical properties start to make a lot more sense.


The Notion API

The public beta of the Notion API is out now! It’s a pretty exciting announcement, as Chris writes:

This is a full-blown API, so you can do things you’d expect to be able to do, like cURL for users, the content of pages, and manipulate databases. They have detailed documentation, expected barriers like rate limits, and even a JavaScript SDK.

This changes the game on some existing services. For example, Super was always a pretty neat way to make a Notion-powered website, but it felt a little risky to me. What if Notion didn’t like that usage and cut it off somehow? Or released their own similar tool? Meh, not risky anymore. Apps like Super can rest easy knowing there is a real API for this so they don’t have to do whatever workaround they were doing before (scraping?) and this kind of usage is likely encouraged, if anything.

Chris then shows how he set up a form on the ShopTalk website for asking show questions — it’s an embedded Wufoo form that updates a page in Notion automatically when someone submits a question. What excites me about all this is how I can see Notion being used as a kind of database and content management system for websites.


Long Live RSS

The Chrome team just launched a neat experiment that lets us follow websites right there in the browser, just like how you can subscribe to an RSS feed with an app like Reeder or Feedbin:

In the coming weeks, some Android users in the US on Chrome Canary may see an experimental Follow feature designed to help people get the latest content from sites they follow. Our goal for this feature is to allow people to follow the websites they care about, from the large publishers to the small neighborhood blogs, by tapping a Follow button in Chrome. When websites publish content, users can see updates from sites they have followed in a new Following section on the New Tab page:

This is really exciting stuff because, under the hood, it’s all RSS; no proprietary formats here. But RSS was always a bit too complicated, always too far away from the actual browser to work for most people, I reckon. And it’s probably going to take a lot of educating folks that a website is something you can “follow” just like a Twitter account.

I hope other browsers like Safari and Firefox follow suit.


How to Create Neon Text with CSS

Neon text is a nifty effect — especially in dark mode — and one that I don’t see on enough websites. Thankfully, though, Silvia O’Dwyer has written about how to make text glow like neon signs with nothing but CSS:

I love how Silvia explores all the different ways to animate neon lights. Just by adding a few animations with @keyframe, it’s possible to make these static bits of text really come to life. Also, this reminds me of the excellent branding for the Typographics conference back in 2017:


CSS Thermostat

Jon Kantner’s excellent thermostat powered by CSS and Greensock is worth checking out; as you drag your mouse across it you can set the temperature. It’s certainly neat to see how the light moves across the surface of the device.

Also: whoa! Look at all those particles inside wizzing around.


AMP is no longer required to rank higher in search results

Marko Saric wrote about the ever-so-good news that Google search no longer gives preferential treatment to websites built with AMP:

Now all the sites have a choice. If you want higher rankings and more traffic from search engines, you need to optimize your site for a better, more performant and faster user experience. And you now have the choice of technology you want to use to get there.

AMP is no longer a Google requirement to create a fast-loading website. You can develop a lightweight site with a great page experience and top Core Web Vitals scores even without using the restricted and Google-controlled way of building a website.

I think this is wonderful news. For years, folks rang the alarm that the AMP format was anti-competitive and monopoly-like behavior from Google. So this is good news — now, websites that are fast and accessible should get better search results, not because they’re made in some proprietary format. I ultimately think that’s great for us web developers and great for our users as well.


Monitor and improve Core Web Vitals with Raygun

Are you ready for Core Web Vitals? Start tracking Google’s modern, customer-centric metrics with Raygun, and get all of the diagnostics you need to take action. Pricing starts from as little as $8 per month, so get your competitive edge today!


Jetpack Boost

Several of Jetpack’s performance-focused features are moving their way over to Jetpack Boost. For example, lazy-loading image (a huge performance win) is now in Jetpack Boost and you can turn it on with the flip of a switch. The most amazing, and brand new, feature of Jetpack Boost is that it does Critical CSS handling for you, which is also a big performance win and very difficult to do by hand.

Psst! Automattic is looking for a Product Marketing Manager on their WooCommerce team to partner with cross-functional leaders to bring new eCommerce products and features to market. Apply now!


[Chris]: Blog posts are such a powerful learning tool. Particularly interactive ones. I bet you’ve seen Josh Comeau’s posts lately, like Boop!. In that post, Josh gets to explain an interactive concept that really benefits from being able to experience it.

Amelia Wattenberger absolutely crushes this kind of blogging as well, with posts like What does 100% mean in CSS?. Even a simple width-slider can go a long way in driving home a concept, like PPK did in fit-content and fit-content().

I suppose it makes sense that I’m bullish on this, as one of the core ideas in CodePen is that you can embed Pens. That opens the door, I hope, to anyone to more easily embed interactive examples into blog posts. Even if you don’t built the interactive bits yourself, you can make the code editor live and that’s naturally interactive.

Ana Tudor makes use of CodePen quite a bit in articles like Taming Blend Modes: `difference` and `exclusion` where some of the Pens are specifically instructional, showing you how a concept works, and some are demonstrations of the technique in use.

What got me thinking about this again is Maggie Appleton’s post Learnable, Visual Programming Patterns. It’s not an interactive blog post in and of itself, but gets into, for one thing, the expectations of programming and outcomes. The industry standard is “column-based” coding interfaces (which is the first I’ve heard it called that, but now that’ll be locked in my brain forever). The alternative being… not that. Something more about manipulating the componentry of the task at hand. Perhaps something that these kind of blog posts hint at.

While visual programming isn’t great for the scale of complexity professional programmers deal with, it’s ideal for people who are learning to code. When we simply need to explain what’s happening under the hood, graphical representations are the best way to help people build clear mental models.

I’m pretty optimistic that learning programming is on a fast track toward improvement. Ya know, if the trajectory of the last couple decades have anything to do with it.

But all this learning-the-web-on-the-web is a pretty obvious fit, isn’t it? Does this type of thing hold up to ideas far away from programming? Heck yes, it does. Read Bartosz Ciechanowski’s Internal Combustion Engine and tell me you aren’t basically a mechanical engineer now. That post is just incredible.