I like to think of CSS as a conditional design language.
It totally is! We tend to think of stuff like @media queries as the conditional part:
@media (max-width: 550px) {
.grid {
grid-template-columns: 1fr;
}
}That’s true, and new stuff like container and style queries are giving us more “conditional” stuff to work with. But it might be better to think of literally everything in CSS as conditional. Every selector you can write is conditional in some way. Just a sector like aside is conditional — it says, only style elements that match that selector. To grok CSS, you are grokking a massive set of conditions. As Ahmad indicated:
.alert p:empty {
display: none;
}This is a big logical if statement. IF the element is a paragraph. IF that paragraph is empty. IF it is a child of another element with a class of alert. All those IFs have to be true for the styles to apply.
You could take conditional CSS another step up though, meaning conditions by which to load the entire .css file at all.
Vadim Makeev wrote up some interesting experiments around all this. Say you do:
<link rel="stylesheet" href="style.css" media="print">The browser is smart enough not to load that CSS file at all (unless you’re printing, natch).
You can also do this:
<link rel="stylesheet" href="base.css">
<link rel="stylesheet" href="mobile.css"
media="(max-width: 767px)"
>Butttttt, the browser will actually load both of those files regardless if the media matches or not. So no obvious immediate benefit, but that’s where Vadim’s research comes in. While all the files with non-matching media (queries) still load, the browser is smart enough to make the non-matching stylesheets load with a lower priority. At least in Chrome and Firefox — Safari has some bug that makes the priority levels not provide the perf benefits.
Pretty cool I think. Doing this kind of work by hand feels onerous though, I’d love to see build processes deal with it automatically.
Ya know I was scared for Mozilla & Firefox for a while. Those big layoffs in 2020 included many browser engine engineers and it seemed like it would be hard to continue to be a viable browser engine alternative without a strong team there. But I was essentially wrong. Since then they’ve shipped plenty of important web platform features at a decent pace, including the ever-important Container Queries and new color formats. Putting MDN on GitHub happened after the layoffs too and that seems like a massive thing to get shipped.
Last year WIRED asked Is Firefox OK? There wasn’t really an answer there, but some good information. We know Google provides the bulk of their income, but they showed really strong growth with their own products and services, saying 14% of all revenue was that back in 2021. They’ve clearly been trying new stuff to increase that, so things look on the right track to me.
I like to see little stories like this: Mozilla fixed an 18-year old CSS bug in the Firefox browser. So they aren’t just playing catch up, they are getting details right along the way too. Better late than never. This one was a weird bug with ::first-letter, the real ticket for doing drop caps:
They said it was kind of a bandaid for now but still cool. Speaking of drop caps though… ::first-letter was always fraught for this purpose. Much better would be to support initial-letter. C’mon Firefox, you can do it!
Michelle Barker on Resizing with CSS:
One drawback is the resize control is only positioned in the bottom right corner of the element, and it’s not possible to style it. It would be nice to have this customiseable ability, and increase the area of the resize control.
Yes!
That’s literally my opening thing in Things CSS Could Still Use Heading Into 2023. Just imagine the CodePen editors. So many things resize, and the ability to do that in HTML and CSS alone would be super sweet. But probably with JavaScript callbacks so we can do stuff like save/persist what has changed in the UI.
And ya know, that makes me think about how we only just got a scrollend event in JavaScript, maybe we should get a resizeend event too.