[Robin]: Happy holidays, folks! This will be the last newsletter from us this year and so we just want to say thanks for reading. We covered so many topics in this newsletter over the last twelve months that I’m not even sure to begin. There was drama! New features in CSS! Weird hacks that I didn’t think were possible! Just keeping up with everything was tough, yet alone learning how to apply it in my day-to-day work. But writing this newsletter has definitely helped me figure things out and get a lay of the land when it comes to front-end development, so I hope it helped you, too.
I reckon the common pattern this year in the newsletter was that, yes, all these tricks and front-end stunts are extremely cool but keeping up with this stuff shouldn’t be a burden. We try pretty hard to make sure this newsletter doesn’t feel like an endless list of things. We don’t want to overwhelm you, and we certainly don’t want this newsletter to be homework. On that front, there will be more of the same next year because ultimately we want learning about front-end development to be a ton of fun and we hope to encourage everyone to experiment with old techniques and new kick-flip things (without the stress of FOMO).
Anyway, we very much hope that next year brings you good fortune and what not but we also hope you stick around to see even weirder, wilder changes in the front-end development space.
We’re pretty darn excited.
:has() is :here()
Speaking of excitement: stop the press! The :has pseudo-class just shipped in Safari Technology Preview which means it’s the first time we get to play around with a parent selector in the wild and test it for ourselves.
But wait, what’s :has again?
I tried my best to answer this question earlier this year when I bumped into some tutorials I didn’t understand. But the general idea is this: it lets us style an element if that element contains something within it. Like this:
div:has(p) {
background: red;
}If this div has a paragraph in it, then it would have a red background. Neat! We’ve been asking for parent selectors for more than a decade because there’s a bunch of scenarios when you want to customize an element depending on whether it contains an element inside it. And today that’s just not possible.
I’m really excited about :has() shipping more browsers because I think it opens a million doors in CSS that I can only barely get to grips with right now. More on this in the new year for sure (this might be the biggest development in CSS for the next 6 months or so, but we’ll see).
Cool things you can do with CSS and text
Here’s a great reminder from Ale that you can create gradient text by using just three CSS properties like this:
.gradient-text {
background-image: linear-gradient (45deg, blue, red);
color: transparent;
-webkit-background-clip: text;
}
I love reminders like this because I often find myself thinking that text can only be one color or style—and that’s it. Kinda like that style of websites that appeared in the early ’10s where CSS3 unlocked a ton of weird new experimental stuff like CSS text shadows. In that post there, Tim Brown shows how the ever-so-simple CSS property text-shadow can do rather magical things:
Perhaps we lost some of this stuff on the web thanks to the move to flatter and more minimal interfaces, but man. I think it’s always great when a single (or just a few) CSS properties can make things really pop.
Underline spelling squigglys
I very much appreciated this post about the new spelling and grammatical tools we’ll be getting in CSS. It boils down to two new pseudos that look something like this:
::spelling-error { text-decoration-line: spelling-error; }
::grammar-error { text-decoration-line: grammar-error; }Delan Azabani writes:
Modern web browsers can help users with their word processing needs by drawing squiggly lines under possible spelling or grammar errors in their input. CSS will give authors more control over when and how they appear, with the new ::spelling- and ::grammar-error pseudo-elements, and spelling- and grammar-error text decorations. Since part 1 in May, we’ve done a fair bit of work in both Chromium and the CSSWG towards making this possible.
What I love here is how Delan shows that simple changes we want to make to the underline spelling squigglys can mean really complex and challenging engineering problems under the hood. And so I warn you with this post, it gets real weird (and very, very good).
Websites we like: henry.codes
Completely random side note: have you seen Henry’s website? I think it’s probably the most interesting and weirdest personal site I’ve seen in years. The animations! The typesetting! The everything!
I’m certain there are tiny little details here I’ve missed but it’s genuinely inspiring stuff. Make sure to poke around and give it some time: it’s just great.
Sponsor
The complete guide to error monitoring and crash reporting
Software bugs are frustrating for everyone. End users lose patience and leave, developers struggle to reproduce errors, and businesses lose customers without even knowing why. That’s why modern development teams need error monitoring more than ever.
[Chris]: We’re down to Apple, Google, and Mozilla making web browser engines. This past decade lost both Opera and Edge. There are some small new players, but it’s hard to imagine them getting close to parity with what we have now, then having a business model to sustain them, then getting market share enough to keep it rolling for the long term.
In Webrise, Brian Kardell talks about the precarious nature of all this:
Imagine, for example, that Apple is convinced to match or even exceed Google’s contributions. Yay! A boom in innovation! Great! It seems hard to imagine Mozilla not being left behind. Maybe Google responds in kind and we enter a sort of “new arms” race. Again, great for a lot of things, but sustainability isn’t one.
These three businesses will change, and when they do, they will evaluate and respond as businesses do. Maybe they look to trim what they perceive to be fat. Maybe they pour gas on the fire of what starts as a small marketing war. Maybe they spin down the browser engine efforts entirely. All these things have happened and will happen again, and browsers are at the mercy of it. Even if the standards bodies were operating in an expedient and healthy manner, if web engine implementors are crippled or gone, browsers stop moving or go away.
An interesting aspect here is that the big three remaining are all open source. Brian notes that all of them on average take about 25% of code contributions from outside, which is even largely funded from the outside. If that ramped up, when those days of reckoning come, perhaps there is less danger. Maybe the money that ultimately powers the web can be spread out.
10 companies agreeing to invest $10k apiece to advance and maintain some area of shared interest is every bit as useful as 1 agreeing to invest $100k generally. In fact, maybe it’s more representative.
Maybe we’ll see this type of thing grow. I could see it snowballing once it has some momentum. At the moment it feels a little like why would I give money to a company that makes more money per second that I make in a lifetime, but that perspective might change as there are more browsers based on these open source engines. You aren’t giving money to Google/Apple/Mozilla; you’re contributing to the open-source Chromium/WebKit/Servo which powers this whole ecosystem of browsers based on them.
I’m not really qualified to speculate what might happen here, and I don’t have the same perspective as Brian and others a lot closer to the sausage factories — but I’m not particularly worried. I feel like we are likely still on the browser engine diversity downswing, and after that, we’ll see forking and diversity of the winning engine(s) with an upswing of contribution to what remains.