There is this sentiment that you don’t design the homepage of a site first. For most sites, it’s an anomaly. It’s unlike any other page and not something to base the patterns you use for the rest of the site or help inform other pages.

You might call it a one-off.1

One-offs are OK! A world without one-offs is very boring. But a site chock-full of one-offs leads to familiar problems: inconsistency and non-reusable CSS that leads to bloating and maintainers that don’t really know what’s used and what isn’t.

What are we to do?

Brad Frost thought about this recently with his article Where to put one-off components?:

It’s quite likely that individual applications contain components that fit the very real needs of a specific application (think calculators, holiday-season parallax hero units, context-specific interactive maps, and so on), but may not be able to be immediately (or ever) abstracted into a generic, reusable component that’s included in the design system.

And Ethan Marcotte:

Here’s an example: let’s say you’ve designed a splashy-looking hero image. (Nice work, by the way. It looks very splashy.) Let’s also say its scope is fairly limited: perhaps it’s being used on a small number of pages, or it’s tied to one specific section of your website. In other words, it’s generic enough to be a pattern, but it’s not a widely-used one. As you might have guessed, this is a dangerous place for a pattern to be. If a pattern feels a little idiosyncratic, that should always prompt us to ask: should your team keep the pattern, or remove it? Thing is, there’s no single, easy answer to that question. Every pattern is different, and each pattern’s value is variable. Maybe we’ll drop that pattern altogether; maybe we’ll combine it with another, similar pattern

Brad connected the idea of a one-off to Harry Robert’s shame.css concept:

The idea of shame.css is that you have a totally new stylesheet reserved just for your hacky code. The code you have to write to get the release out on time, but the code that makes you ashamed.

But maybe a CSS file like that doesn’t need to be reserved just for “hacks” or shamefully quickly-written fixes (hey, it’s better than inline styles), but also for one-offs.

From a developer-in-charge-of-styling perspective, it’s interesting to consider how different styling methologies come into play here. For those travelling the atomic CSS road, in a sense, everything is a one-off. You might still have a pattern that is visually or behaviorly a one-off because of how you’ve built it, but not because it uses a different set of CSS. Callum Jefferies on his experience with atomic CSS:

I no longer had to think about how to organise my CSS. I didn’t have to think about what to name my ‘components’, where to draw the line between one component and another, what should live where, and crucially, how to refactor things when new requirements came in.

So, too, with the 36 flavors of CSS-in-JS. When your styles are attached to your components, all components are one-offs. Stop using that component, stop using those styles.

Apparently one-off is a fairly new expression: