262: CSS Nesting, Safari Drama, and the CSS Paint API - CSS-Tricks

?

Nesting CSS classes is pretty handy. If you’re familiar with preprocessing languages like Sass and Less then you’re probably used to nesting like this:

.card {
  .card-text {
    font-size: 1em;
  }
  &.card-large {
    padding: 2em;
  }
  body.home & .card-title {
    font-size: 2em;
  }
}

In fact, I’m so used to writing Sass like the above that I often forget nesting isn’t available in regular CSS. Well! Nesting like this is coming to a CSS file near you. That code above is equivalent to writing this…

.card .card-text { font-size: 1em; }
.card.card-large { padding: 2em; }
body.home .card .card-title { font-size: 2em; }

Using that & is a handy way to keep styles bundled together and is often easier to read than duplicating the .card CSS class over and over again. That’s why I’m pretty excited about this and I’d love to get to a place where for most projects I don’t need to use Sass (which is my preprocessor of choice). That’s not to say Sass is obsolete though, as Miriam writes:

?

I spotted two interesting CSS things from Elad Shechter this week. First up, is fit-content which you can use like this:

.element {
  width: fit-content; 
}

This will keep that element as display: block but now it’ll only expand to the width of the content inside the element, as Elad shows in this demo. Pretty handy, plus it has full browser support.

Note from Chris: I used it recently right here on the web-based newsletter design. Basically figure { width: fit-content; }, that way if the figure contains an image (or other content) that isn’t as wide as the container, the figure itself shrinks in width to the container (but stays block-level).

Next up is inset, which I seem to always forget about:

.element {
  position: fixed;
  inset: 0;
}

This is the same as declaring top, bottom, left, and right at the same time. Pretty nifty.

?

I think I read 7,321 blog posts this week about how Safari is difficult to work with. This post by HTTP Toolkit has the best breakdown of all the criticisms, from how Safari takes too long to fix bugs, to the lack of features that have been present in other browsers for a long time now:

According to Can I Use’s metrics, Safari is lacking about 10% behind Firefox and 15% behind Chrome in feature support. That’s including every basic feature like HTML images, forms and links – so it’s a major underestimation of the modern feature set.
Meanwhile the web platform tests dashboard (unaffiliated with any vendor, with contributors from Mozilla, Google, Apple and across the industry) has its own metric for this, a count of browser support for their list of core web features most used by web developers. Safari is not doing well:

Oof. Dave Rupert also wrote about one-offs and low expectations with Safari where he describes how much of his time he has to spend thinking specifically about Safari’s peculiarities:

There’s a lot of history here. WebKit — being a part of Apple — plays it slow and a bit close to the chest. Historically, they’re pretty tight-lipped about the small number of features they’re working on and uninvolved in community outreach. Quarterly updates to Safari Technical Preview have been an awesome consolation prize, but after years of waiting I find my expectations for the annual release of Safari (specifically Mobile Safari) are intolerably low. This creates an increasing amount of apathy in me that the situation with Safari will get better soon.
[…] but my problem isn’t feature requests, my problem is patience.

Double oof.

I’m pointing to all this hot drama not just so we have a target to dunk on though. We shouldn’t take any satisfaction from calling out Safari but instead, we should want them to do better so that there’s thriving competition in the browser space.

The CSS Paint API looks neat. George Francis wrote about how to get started conjuring generative blobs with this fancy new API:

The CSS Paint API allows us low-level access to CSS itself(!) through an HTML5 <canvas>-like drawing API. We can harness this power with something called a worklet.
Worklets, in short, are JavaScript classes. Each worklet class must have a paint() function. A worklet’s paint() function can programmatically create an image for any CSS property that expects one.

Once we’ve created our worklet we can then use that in our CSS like this:

.element {
  background-image: paint(blob);
}

We can then use CSS custom properties to change properties within the worklet:

.element {
  --blob-seed: 123456;
  --blob-num-points: 8;
  --blob-variance: 0.375;
  --blob-smoothness: 1;
  --blob-fill: #000;
  
  background-image: paint(blob);
}

It’s definitely worth checking out George’s examples here as his tutorial goes step by step for getting the worklet up and running in the browser.

Note from Chris: if you happen to peep the CSS-Tricks header and footer backgrounds in a CSS Houdini paint()-enabled browser, you’ll see some generative splotches that is George’s work.

Tabnine: Code Faster with AI Code Completions

Do you write code? Tabnine is an AI assistant for individual developers and teams — trusted by millions of professionals around the world. Tabnine’s AI will help you write code faster and eliminate unnecessary errors – all in your favorite IDE.

Get Tabnine

Take the 2021 Jamstack Community Survey

Are you a developer, DevOps, tech leader, or part of a marketing team building on the web? Netlify wants to hear from you. Last year’s survey of more than 3,000 respondents revealed that Jamstack was no longer a new kid on the block. This year, we’re asking some of the same questions and some new ones to understand what has grown or changed year over year.

Take the survey

[Chris]: Last week I rounded up some links of people’s thoughts on the Safari 15 UI changes. I don’t feel particularly opinionated myself on things, as I’m not a heavy Safari user, but I get the impression that most people in my webdev circles aren’t particularly concerned with the UI (neat tricks, if anything) but are awfully concerned about Safari in general as a browser. And people in AppleTech circles are very not into the UI choices (fair is fair, people were reacting to a beta, and that beta has undergone changes).

After publishing that, there was another little surge of blog posts from webdev people particularly displeased at the state of Safari:

Safari isn’t protecting the web, it’s killing it — Tim Perry has a big list of things Safari is just straight up missing, that aren’t even in that tricky area where Safari can claim it’s because of user privacy.
For developers, Apple’s Safari is crap and outdated — Perry Sun gets more into the lack of PWA and WebRTC support.
One-offs and low-expectations with Safari — Dave Rupert gets into how every project has Safari-specific stuff in it, and it seems to be getting worse not better. He points to Maximilano Firtman’s list, which is again a totally different set of missing features.

I think people are extra displeased about all this because, on Apple devices, there is no choice in browser engines. It’s Safari or nothing. Compounded by the fact that Apple has more money than God so could fix this if they wanted to.