This week: SVG Mask Experiments, Particle Galaxies, and Blend-Mode Cutouts

Chris' Corner

CSS resets are still a thing! I’m not entirely convinced we even need them anymore, but that certainly isn’t reflective of industry behavior. CSS developers, by and large, slap one into every project. My argument against them is that browsers are fairly consistent anyway and once you get coding on a project, there is enough CSS that sets things to get things in shape such that they didn’t need to be reset to begin with.

I find that the “resets” of recent times take the form of a collection of opinionated snippets that the author likes. But whatever, I don’t actually care that much, if you like using them on projects, go nuts, you probably build more websites from scratch than I do these days anyway.

As I said, there is plenty of evidence that people still slap them into new projects. For example, I was poking around the new Steve Jobs Archive site the other day and saw they used Elad Shechter’s The New CSS Reset in there. And lots of public developers want to have their say. Eric Meyer is absolutely famous for his. I remember Normalize being an absolute rager and light drama when Jonathan Neal pulled away to do his own. The world perked up when Bootstrap made their own. Andy Bell’s went viral a few years back. Josh Comeau weighed in with what he likes. Most recently, I’ve seen Elly Loel’s tweet get a lot of attention.

I can’t read through a single one of those examples above without scrutinizing every line. Some of it I’m like oooo clever I like it. Some of it I’m like uhm that looks very dangerous and I would never. But that’s what makes them fun and probably part of the reason new ones seemingly get so popular when they drop. CSS voyeurism, as it were.

---

Allow me to let someone else be skeptical for a moment. Back in 2011 is when Ethan Marcotte’s book Responsive Web Design dropped. That same year, Luke Wroblewski published Mobile First, a related concept that essentially said since we’re designing for both large and small screens, we ought to design the small one first as it forces us to confront constraints and make potentially more difficult decisions upfront.

Fast forward 11 years and Patrick Clancey is saying Mobile-First CSS: Is It Time for a Rethink? Patrick is honing in on the CSS aspects here, which you could argue is just a part of mobile-first methodology generally, but hey it’s all related.

I’m developing CSS with a focus on the default values much more these days. Since there’s no specific order, and no chains of specific values to keep track of, this frees me to develop breakpoints simultaneously. I concentrate on finding common styles and isolating the specific exceptions in closed media query ranges

So it’s not desktop-first either, it’s common-ground-first.

I don’t have a great sense of the popularity of mobile-first thinking these days. It would be interesting if we could somehow query the entirety of Figma to see how many desktop mocks have been created vs mobile mocks. My hunch is that there is no clear winner of which goes first, it all gets done in the end.

---

While I’m being all critical this week, let me end with an idea I had earlier in the week:

HTML / CSS / JS processors should pledge:

1. Be certain that the syntax you are introducing will become part of the language or 100% not interfere.
2. Or, be certain that the syntax you are introducing will never be part of the language. In this case, use a custom file extension.

I just have this hangup about things that steamroll native languages. Like I don’t think you should just make up HTML attributes and use them just because you like how it looks. HTML has data-* attributes you can use for that, so that’s what you should do. Doing it on one website probably doesn’t change the world, but if your little attribute idea somehow gets traction and is used on lots of websites or some popular website, it means that the future of the language is essentially bullied away from ever using it.

Again, tiny infractions here and there don’t harm much, but web history has plenty of examples where frameworks and processors have made steamrolling choices that literally have forced native languages to zig instead of zag. So I say draw a line in the sand. Just never do it. There is always another way.

That’s a reason I’ve always been skeptical of PostCSS. All by itself, PostCSS is just a CSS-to-AST machine with a plugin structure for doing CSS transformations. There are loads of these plugins. One of them is PostCSS Preset Env (a nod to Babel’s preset-env) which is essentially a set of smaller plugins that transform a “future syntax” of CSS into something that CSS-of-today understands. Not all future CSS things process into a nice fallback or can be prollyfilled (a polyfill of syntax that will "probably" happen) in this way, but some can! Nesting and custom media query variables are good examples of ahead-of-time processable features.

So all that is a good example of #1. But PostCSS doesn’t enforce or even encourage you adhering to that principle. For example, this plugin Simple Grid invents new properties like create-row, create-column, create-grid, and so on. Are those coming to CSS? Probably not, but you never know. There is nothing preventing it. There is no prefix or syntax that CSS would never use there. So it’s a violation of #2 of my pledge idea. I think it would be better not to steamroll the language here and find a way to do it where the syntax could never be a part of the language. Then, additionally, because what you are writing is no longer native CSS, give it a different file extension. Don’t use .css, which to me implies that the contents are the native language. Calling it .postcss makes fine sense to me, and I wish they would encourage that rather than the “It’s just CSS” vibe, which as we just talked about, sometimes it is and sometimes it ain’t! Just draw a line in the sand and protect the native language.

PostCSS has been around forever and I’m sure largely had a positive impact on the web, so I don’t want to be too hard on it, I just think the web is better off long term when we don’t steamroll the language. This same thing comes up in new CSS processing ideas as well. Take Token CSS, a very fresh new processor that helps you output values from design tokens. It’s a way of keeping your design tokens in JSON and then referencing them in CSS directly by name, like padding: md; color: gray.3;. The same problem pops up here as the Simple Grid plugin, but this time with values instead of properties. The value md doesn’t mean anything in CSS today, but there is nothing preventing that, hence the steamrolling, a violation of #2. But let’s say you just love this syntax and you don’t care about the language steamrolling, then at least do the custom file extension thing. Don’t imply that “it’s just CSS” when it isn’t.

OK skeptical week is over, back to our regularly scheduled programming next week.