Jens Oliver Meiert

CSS Shorthand Syntax Considered Important

Post from December 21, 2016 (↻ August 7, 2017), filed under .

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: Respected Harry, who usually gives good advice, just gave 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 just 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. (Harry, feel free to expand on your points, maybe we can squeeze even more out of this to everyone’s benefit.)

[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 that 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 so far 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 this will be 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. 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?

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 the Author

Jens Oliver Meiert, photo of July 27, 2015.

Jens Oliver Meiert is a developer (O’Reilly, W3C, ex-Google) and philosopher. He experiments with art and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences.

There’s more Jens in the archives and at Amazon. If you have any questions or concerns (or recommendations) about what he writes, leave a comment or a message.

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:

    Fair enough, Šime. In my view what you’re describing is an oversimplification that leaves out important detail about what to think about and how risk of bugs should be defined (and what amount of risk would be acceptable), but I get the basic idea of what you’re saying.

Read More

Have a look at the most popular posts, possibly including:

Or maybe say hi on Twitter, Google+, or LinkedIn?

Looking for a way to comment? Comments have been disabled, unfortunately.

Flattr? Found a mistake? Email me, jens@meiert.com.

You are here: HomeArchive2016 → CSS Shorthand Syntax Considered Important

Last update: August 7, 2017

“If there is any secret, it is missed by seeking.”