[Robin]: Here’s the deal: I’m scared of Houdini. Not the illusionist famed for jumping off waterfalls and burying himself alive, but the newish set of APIs available in CSS. That’s why I so thoroughly enjoyed this piece by George Francis about creating generative patterns:
Recently […] CSS was gifted an exciting new set of APIs known as Houdini, and one of them — the Paint API — is specifically designed for rendering 2D graphics. For us web folk, this is incredibly exciting. For the first time, we have a section of CSS that exists for the sole purpose of programmatically creating images. The doors to a mystical new world are well and truly open!
[…] Paint API worklets are fast, responsive, and play ever so well with existing CSS-based design systems. In short, they are the coolest thing ever. The only thing they are lacking right now is widespread browser support.
That sounds neat as hell, and the effects are even neater:
All of this here—the dots, the little colorful shapes, and the green background—all of that is done with Houdini. It’s a big deal because it unlocks a treasure trove of possibilities where before you’d probably just make this with Photoshop or some image editing app and be done with it. But now that it’s in CSS we can do some weirdo generative art stuff with it.
Let’s walk through getting started with the CSS Paint API, step by step:
- You create a new JavaScript file to house your “worklet.”
- That worklet is code that runs on a separate browser thread and has to live in a standalone
.jsfile. - We can start writing our JavaScript like this…
class Worklet {
paint(ctx, geometry, props) {
const { width, height } = geometry;
ctx.fillStyle = "#999";
ctx.fillRect(0, 0, width, height);
}
}
if (typeof registerPaint !== "undefined") {
registerPaint("workletName", Worklet);
}- All this is doing is making a gray background. Let’s load this worklet and make some HTML to apply it to…
<div class="element">
This div has the background set by the CSS Paint API
</div>
<script>
if (CSS.paintWorklet) {
CSS.paintWorklet.addModule('worklet.js');
}
</script>5. And finally, in our CSS, we apply that worklet to that .element div in our HTML:
.element {
background-image: paint(workletName);
}All of that leads to this remarkable, ground-breaking design:
Okay, so it’s not much to look at but it takes all the scariness away from this stuff for me. You write some JavaScript to make some shapes and colors and whatnot, then write some HTML as well as some CSS to apply the output to. It’s simple enough, really. But from here on out we can start doing all the really exciting generative art stuff that George writes about in his article. We can make buck wild shapes that change and distort with each refresh:
I mean, okay, it’s no gray background like my excellent design, but sure. This is fine, I guess.
Joking aside, isn’t all this really quite impressive? It feels like one of those things that opens up so many possibilities, so many weird new doors in CSS.
⿹
Multi-directional websites are extremely interesting to me. Take this post by Alaa Abd El-Rahim that goes into extreme detail about how to support multiple languages with CSS.
Many business websites need a multilingual setup. As with anything development-related, implementing one in an easy, efficient, and maintainable way is desirable. Designing and developing to be ready for multiple languages, whether it happens right at launch or is expected to happen at any point in the future, is smart.
There’s something extremely elegant about all this to me. Having one codebase, one set of semantics, and then, with a flash of CSS, you can make a truly accessible website. Here’s some particularly interesting CSS used in the post:
html:lang(jp) .about__text {
writing-mode: vertical-rl;
}What this is saying is that when the HTML element is set to Japanese (like <html lang="jp">) then this chunk of HTML should switch out the writing mode from left-to-right to right-to-left. Smart stuff.
This is when you also start to see CSS properties like margin-block-end and margin-inline-start. These are logical properties that are sort of going to replace margin-top and margin-left, etc. That’s because “left” and “right” don’t really make sense on a website—those are entirely dependent on the writing direction of whatever language a website is set. Instead, “start” and “end” make a lot more sense in that world.
But getting used to that is going to take a long while, as Jeremy Keith writes in this reply to Alaa:
It’s like when you’re learning a new language. At some point your brain goes from translating from your mother tongue into the other language, and instead starts thinking in that other language. Likewise with CSS, as some point you want to stop translating “left” and “right” into “inline-start” and “inline-end” and instead start thinking in terms of inline and block dimensions.
👥
Chris wrote about the ethics of tracking users on CSS-Tricks with Google Analytics. It’s a tough situation because, yes, privacy is absolutely important, but also advertising is how CSS-Tricks keeps the door open.
For some folks that crosses a line, but for others that’s just how the internet works:
I write all this just to help me think about it. I don’t want to sound like I’m being defensive. If I come across that way, I’d blame my own inertia for following what have felt like industry standards for so long, and being indoctrinated that those practices are just fine. I don’t feel like I’m crossing major ethical boundaries at the moment, but I’d rather be someone who questions myself and takes action when appropriate rather than tying a bandana over my eyes.
Personally, I see a big difference between anonymous and specific user data. Should I be able to see that 100 people viewed this page? Sure. Should I be able to see which people accessed a page, how long they viewed it, and which websites they went to afterwards? That’s a big no from me.
There’s a moral line that’s fuzzy around all this, at least until it suddenly becomes extremely clear.
✨
Neale Van Fleet made a handy little system for animated entrances in CSS. Little staggered animations like this can make a big difference to how you introduce your app to folks:
I really like this! Neale’s suggestion though is that we can create little CSS classes that we can reuse throughout our websites, sort of like Animate.css which is an enormous library of CSS snippets that I’ve found very useful from time to time.
One last point from Neale here: always make sure to respect accessibility preferences with this media query:
@media screen and (prefers-reduced-motion: reduce) {
.animate { animation: none !important; }
}That’ll disable all animations for folks who have turned them off at the OS level. As Eric Bailey wrote a while back:
Using this media query could spare someone from having to unnecessarily endure a tremendous amount of pain for simply having the curiosity to click on a link or scroll down a page.
↔️
There’s a ton of ways to move things around and create a layout with CSS. That’s why Stephanie Eckles made this extremely good Pen that shows all the ways to line things up in CSS.
There’s a lot! And I can definitely see why some folks who are unfamiliar with CSS might look at this and think, “Wow! Why is there ten thousand ways to do the same thing with CSS?” But that’s only because the context changes and you might need either of these depending on the problem you’re trying to solve.
✍️
Josh Comeau wrote all about his custom CSS reset, which is relatively small in comparison to other resets I’ve seen, but there’s a lot going on with this one. He walks through each part of it, step by step, and I couldn’t agree with this bit enough:
Feel free to copy/paste this into your own projects! It’s released without any restrictions, into the public domain (though if you wanted to keep the link to this blog post, I’d appreciate it!).
I chose not to release this CSS reset as an NPM package because I feel like you should own your reset. Bring this into your project, and tweak it over time as you learn new things or discover new tricks. You can always make your own NPM package to facilitate reuse across your projects, if you want. Just keep in mind: you own this code, and it should grow along with you.
Sponsor
The Developer’s Guide to Core Web Vitals
Core Web Vitals present developers with a new challenge and a new opportunity to improve the user experience. In this definitive guide, you’ll get best-practice advice, a proven workflow, and actionable tips to start improving Core Web Vitals today.
Sponsor
CodePen Pro
CodePen PRO combines a bunch of features that can help any front-end designer or developer at any experience level. Plus, PRO asset hosting got a major overhaul. Now you can upload more, bigger files, edit images as you upload them, and use our new super-powered asset search and sort!
[Chris]: Chrome Dev Summit 2021 was earlier this month. Here’s a five-minute video recap that they did a good job of putting together. The best part for me is 22 seconds in where Ben Galbraith talks about how they have a new initiative Compat 2021 where the whole goal is CSS interoperability between browsers. This kicked off in March 2021. It’s highly focused on just five things. It’s better to just read that post than have me re-explain them here, but they all seem like worthy targets to me. Would be nice to see stuff from Dave’s list, if you ask me, but that is stuff Safari uniquely needs to address and that path toward third-party contribution to mobile Safari seems a bit foggy, if not downright not happening.
It seems like the work is spread out. Some of it is Chrome needing to fix itself, and some is that Firefox and Safari need fixing, which I guess becomes Igalia’s job, and Chrome pays them to do it? That part isn’t entirely clear, but is the most interesting part to me. Is this Chrome saying we know there are compat issues, so we’re going to… keep working on Chrome a bunch. Or is it Chrome saying we know there are compat issues and we’re going to contribute to all the browsers to fix them, perhaps even more in other browsers — the latter being more useful, and what I hope is happening. I know both Google and Apple have fountains of cash, so, ideally, I’d like to see them both contributing whatever kind of muscle they can to fix interoperability. They aren’t buddies, though, Google and Apple. There is going to be issues. The best we can hope for is that both the web and web developers are so important to them that we essentially demand these issues be addressed, and they do it.
I’m generally optimistic if only because the situation now seems far better than it ever has been. Compatibility has been trending better over time and doesn’t seem to be slowing down. I still worry that, with the proliferation of new web tech, even if we watch companies shoot for good compatibility, they can only work on so much. I’d bet we’re headed into a few years, at least, of very spotty compatibility for new and desirable features.