They say “naming things is hard” not because picking any ol’ name is hard, but because picking a useful, long-lasting, meaningful, understandable, deeply communicative name is hard. Screw it up and you can confuse yourself and others unnecessarily.
We’re in a dev cycle right now on CodePen itself that has me seeing PRs on the regular that boldly re-name entire APIs and every usage of them because they just aren’t doing it for us anymore. We aren’t going to live with bad names, we’re going to re-name them, dammit.
But if you are stuck on picking out a name, or a theme for a set of names, Paul Robert Lloyd has your back here. Working on a design system? Perhaps names from architecture can be inspiration. Perhaps your CMS project could learn from journalism.
A good name you can understand, and quickly. In the case of CSS custom properties, you have no choice but to pick a name, so they are an interesting space to thinking about naming in. Jonathan Dallas does a great job in Naming Variables In CSS. Even if a name in isolation is OK, does it read OK as a group? Could it be re-cased or re-arranged to read better? Great example from Jonathan:
:root {
/* Harder to scan: */
--system-control-accent-color: blue;
--system-focus-ring-color: cadetBlue;
--system-label-color-quaternary: lightGray;
--system-heading-title-font-size: 1.5rem;
--system-subheading-font-size: 1.2rem;
--system-caption-font-size: 0.65rem;
/* Easier to scan: */
--system-color-controlAccent: blue;
--system-color-focusRing: cadetBlue;
--system-color-labelQuaternary: lightGray;
--system-fontSize-headingTitle: 1.5rem;
--system-fontSize-subheading: 1.2rem;
--system-fontSize-caption: 0.65rem;
}Jonathan makes a distinction between descriptive names and value-based names. There are definitely differing opinions on which is preferable, and even people who think you should use both (e.g. a descriptive variable that references a value-based variable). It depends, you could say.
I’m sure you know that some colors in CSS are already named. Jonathan uses CadetBlue a number of times, which is a perfectly valid color in CSS. But you know what isn’t? TheSoulOfChris. Despite it being an obvious firely orange, that name won’t do anything in CSS. But feel free to make it your --system-color-accent.
Should we name all the colors? Could we? David Aerne must think so, based on the Color Names project. So far, they have named 30,200 of the 16,777,216 colors in RGB. 0.18%. Still, impressive (but nobody tell them about P3).
I enjoyed Deepak Gulati’s Bringing 19th century ornamental tile illustrations into a 21st century web app. It resulted in a little app that showcases how the tiling works. One tile, flipped/mirrored, is capable of doing interesting stuff! Design is cool!
There’s some interesting timing here with a little run of Pens I saw. You know how video games sometimes have super weird interesting UI? Like wildly stylized menus and buttons and stuff. Baldur’s Gate is a classic example, and someone must have proposed a challenge of sorts because I saw several examples of putting it off in CSS pretty close together. I think you can imagine while seeing these how they have some of that “design a corner then rotate/mirror it as needed”:
They all nailed it if you ask me!
The web’s best animation framework, GSAP, has a freshly redesigned website.
Congrats gang — looks great! Do I sniff Docusaurus under the hook in those docs?
I once wrote an article about embracing Simple & Boring tech, although while I agree, it was mostly a collection of other people extolling those principles. It tends to be a lesson you have to learn for yourself. If you end up being responsible for technology over a long enough period, it tends to be the least flashy tech that has your back, staying stable and requiring the least maintenance. And thus helping both you and users.
Dan McKinley has a great talk about this called Choose Boring Technology. What’s nice is that Dan has a strong real-world example rather than the kind of vague platitudes I was spoutin’ above. At Etsy, Dan worked on “activity feeds”, and they considered adding Redis to their stack to handle them, but…
But when we set out to build activity feeds, we didn’t have Redis. We did have Memcached. They’re sort of similar in the sense that you can shove a blob in them, and get it back out with a similar API. But they have very different guarantees. The most relevant difference to us here is that Redis is persistent, and Memcached is ephemeral.
What that means is that if you want to build an activity feed with Memcached, you have to do a bunch of extra work. You have to cope with the possibility that Memcached has gotten rid of your data at the moment you want it.
That creates a ton more work when it comes to writing the code to deliver the feature. But we weighed that against the persistent cost of operating a new kind of database, and decided that we’d bite the bullet and build the feature on Memcached.
What happened next? They just didn’t think about the technology for years. Turns out, usage of the feature 20x’d, and the feature was so stable nobody had to touch it. Would that have happened if they added a new technology to the stack. Dan’s answer is a clear: no.
Dave Rupert, earlier this year, talked about boringness as a rather specific virtue of a defensive design system. After listing some 20 attributes of potential <Card /> component, he says:
This component must be defensively designed and built against any permutation of author-supplied content. What was once a humble visual display component is now a content workhorse. Any component has the potential to become a little machine filled with a myriad of rules and requirements. There’s gravity towards becoming a multi-use component.
All these complexities dilute the component towards a bland defensive design, averaging itself against every possible permutation of content. As utility goes up, so does boringness in a design system. And that can be a good thing!
Color contrast is one of the major accessibility failings of websites, as a whole. Fortunately, they are fairly easy to detect failures with automated testing. Fixing them, admittedly, can be a bit boring of work. I take Magnus Rand’s point here: Contrast is boring—can’t someone else do it?
Having sufficient contrast in your website is one of those things which are very important but still very boring to fix—especially if your site uses multiple background colours.
Magnus is being a touch facetious. He’s not saying “some other human please do my job”, he’s introducing some new CSS technology that will help us do the right thing more automatically.
.text {
background: var(--bg-color);
color: color-contrast(var(--bg-color) vs navy, lightseagreen to AA););
}There are draft specs and an early flagged implementation, but unfortunately don’t rush out to use it just yet. I’m a big fan though. I like the idea of having a list of colors from a design system that you are always giving this function, and it will pick the best one depending on any background color it has, even if it changes. That’s good stuff.
I’ll end with another somewhat recent post on the idea of simplicity from Luke Plant.
Of course we all claim to hate complexity, but it’s actually just complexity added by other people that we hate — our own bugbears are always exempted, and for things we understand we quickly become unable to even see there is a potential problem for other people.
Source link
Leave a Reply