CSS Shorthand Syntax Considered Important

Published on December 21, 2016 (↻ October 3, 2023), filed under Development (RSS feed for all categories).

CSS shorthands are no anti-pattern, just as little as universal selectors, just as little as !important, and just as little as no-js would not be one. Okay, back: Harry Roberts, who usually gives good advice, just made another statement that I don’t agree with and caution against, and that is this, that shorthands were an anti-pattern. No, they’re not.

In essence, just like !important, shorthands are an important part of CSS, a tool that wants to be used correctly. (Much anti-pattern talk has the character of, “oh you can hurt yourself with a knife, so let’s ban knives,” instead of teaching people how to use knives well.) I want to build the shorthands case by following Harry’s argument, however, for I believe the points he makes are interesting to look at.

[The shorthand syntax] often unsets other properties that we never intended to modify.

A main point in Harry’s argument, this statement presupposes ignorance, for only the web developer who doesn’t know what they’re doing would use a shorthand; yet I believe what Harry is really getting at is a level of complexity that makes it hard for us to know what side-effects shorthands can have.

Let’s put the first point, ignorance, aside and establish that we want to believe web developers are competent. The second point, then, complexity, leaves me noting at least two things: One, there are not really that many projects as complex that accidentally overriding things using shorthands would go unnoticed (this disputes the “often” part of the argument). Two, from my experience developers tend to get overly cautious in complex projects, and so I’ve made rather the opposite experience from Harry’s: Developers use the longhand declarations far too frequently.

[…] you should only ever do as little as you need to do and nothing more.

I wholeheartedly agree, and again what I’ve seen from Harry is often sound. But let’s look a bit closer at the case, and it’s simple enough: we set background: red, and Harry reminds us that really says, ordered alphabetically,

.btn {
  background-attachment: initial;
  background-clip: initial;
  background-color: red;
  background-image: initial;
  background-origin: initial;
  background-position-x: initial;
  background-position-y: initial;
  background-repeat-x: initial;
  background-repeat-y: initial;
  background-size: initial;
}

Now, irrespective of what background properties the CSS WG has added in the meantime, what Harry now suggests is to just declare background-color: red. Now it’s really important to pay attention, for the following is all about the details.

Assuming no other background declarations (as they would complicate matters), what we end up in case 1 is that we wrote background: red, and all other background properties were put on their initials. But in case 2, background-color: red, these are also all on their initials, because that’s what they’re there for. The net effect in this case is the same, but the result is we wrote slightly more code in case 2, and that is actually a violation of what Harry established, for we have not been doing as little as we needed to.

Now, are we twisting words? I don’t believe so. If we now choose to complicate matters and assume a complex project and that other people have already modified background properties against us knowing, what happens?

That, and this is the problem I miss Harry pointing out, we don’t know. Why don’t we know? Because the issue is now one of specificity. Even if someone else had set a background property that our use of a shorthand would again initialize, it now depends on the specificity of the rules in question (and maybe even on the order) to tell what effect this would have. Harry, I’m sure, warns us about the risk that our rule’s specificity could be higher, and then we’re still in a complex project where our tests might not reveal others’ later problems, but now we’re making two assumptions that, for my taste, bring us on territory where I’d be very cautious to consider code an anti-pattern. (Think of the kitchen knives.)

The key thing to remember is that shorthand is bad when it’s affecting properties that you don’t actually need to modify.

Here, too, we can only agree, and yet the irony is that this is not a statement that makes a point against shorthands, let alone banning them as anti-patterns. In the majority of cases ^{[citation needed]}, shorthands don’t modify anything because, as we’ve seen above, they change some properties’ initial values to their initial values. When these haven’t been touched at all, there’s no change. While we can agree with the statement (I’d still prefer “want” instead of “need” though), it hinges on what I perceive to be a minority of cases, making it not strong enough to warrant recommendations such as not to use shorthands at all.

• Always favor the longhand. […]
• Only write as much as you need and not a single bit more. […]

No to the longhand, yes to keeping it simple.

Now that we may have a case for shorthands and against their criminalization, how can we use shorthands better?

• Generally, be aware that with increasing project complexity, the probability of side-effects increases. (Some try hard to come up with rules to eliminate side-effects, but I believe many such cures are worse than the disease—banning shorthands falls into this category—and that we cannot eliminate risk in big projects.)

• Know what shorthands do. Harry gave a taste in his article.

• Prefer shorthands over longhands.

• Prefer longhands over shorthands when you would need to repeat yourself (this does not apply to initial values).

• Test.

Yet this is a hasty start that suggests us to come up with a more exhaustive list. Shorthands are a valid part of CSS and an important tool, and we simply need to use them correctly.

Good wishes again to Harry, and to everyone fostering good discussions about web development practices. Happy Holidays 🎄

A side note, Harry reminds me to note that instead of writing margin: 0 auto, margin: auto has the same effect and is actually shorter. This is important not to be snarky but simply because many a project uses that “0” for no reason.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)

Comments (Closed)

1. On December 22, 2016, 1:07 CET, Šime Vidas said:

   It’s simple. You can either write background: red or background-color: red. Both work, but the former introduces a risk of bugs in some scenarios. How big is this risk? I don’t know. When you say “in complex projects” and “in the minority of cases”, that sounds like guesswork to me. I don’t like uncertainty and I don’t like bugs. And I also don’t like thinking about these details too much. The background-color: red option does not introduce a risk of bugs, and for that reason it’s the better choice.

2. On December 22, 2016, 11:56 CET, Jens Oliver Meiert said:

   I get what you’re saying—yet at the same time, that same argument can be used to say people should stay home all day. Leaving their home is riskier than staying in. (You can make all sorts of wild statements like this, just because there’s “more risk.”)

   There’s risk and there’s risk. We need to differentiate.