CSS Shorthand Syntax Considered Important
Published on DecĀ 21, 2016 (updated OctĀ 3, 2023), filed under development, css (feed). (Share this on Mastodon orĀ Bluesky?)
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 web developer, manager, and author. Iāve been working as a technical lead and engineering manager for companies youāve never heard of and companies you use every day, Iām an occasional contributor to web standards (like HTML, CSS, WCAG), 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. (I value you being critical, interpreting charitably, and giving feedback.)