Written by Harry Roberts on CSS Wizardry.
There’s a very small but surprisingly significant (and even more surprisingly frequent) issue I spot a lot in other peoples’ code, either when working directly with it, refactoring it, or auditing it: the use of shorthand syntax in CSS.
Typically we would view shorthand syntax as a benefit: fewer keystrokes, fewer lines of code, less data over the wire. Sounds great! However, it comes with a rather troublesome side effect: it often unsets other properties that we never intended to modify.
When we write something like:
…we’re likely to get a red background colour applied to our button. But what we’re really saying is this:
Simply by using the shorter syntax, we have implicitly decided that we want no image to start top-left, repeat x and y, to scroll with the element, and so on…
Nearly every problem, bug, or regression in CSS at scale is happens because we did too much too soon, and further down the line we’re being affected by that. What this basically comes down to is the fact that, with CSS, you should only ever do as little as you need to do and nothing more.
Misusing shorthand syntax is a surefire way to do too much too soon, as thus it should be avoided. CSS is a lot harder to undo than it is to do.
In this example, what we really wanted to say was this:
Here we’ve done exactly what we needed to do, and absolutely nothing else.
One such example I encountered on a client project earlier this year looked a little like this:
background-position: 0 0;
The developer had—understandably—used a gradient syntax generator to create their rather complex radial gradient, but they found that things weren’t rendering correctly at all. Their gradient syntax was correct, autoprefixer was working just fine, but for some reason their page looked really, really broken.
They couldn’t work out at all what was going wrong, to the extent that an issue
was raised which simply said ‘Get Harry to look at the gradients’. Enough years
of experience told me instinctively what to look for, and sure enough, I found
it: hidden away in the Sass for generating gradients was the
This is a problem commonly found in gradient generators, so:
background example is just one of many instances in which we shouldn’t be
using shorthand. Another very common use-case is vertical centring using
margin: 0 auto;:
margin: 0 auto;
The problem here is that in order to use shorthand to define
once—but use it on both the left and right—we had to make a decision about top
and bottom as well. That was a decision we shouldn’t have made, because now
we’re explicitly removing any top or bottom margins that may have been
intentionally introduced elsewhere.
If all you want to do is centre a
div, then don’t mention anything to do with
its top and bottom edges. Favour the longhand version:
Run a quick
grep over your CSS project for the string
0 auto right now and
see what you find.
So far we’ve looked at the problem with inadvertently unsetting other properties, but there is a scenario in which shorthand would be okay. Take for example:
Here we aren’t inadvertently unsetting anything because we do want all four
sides to carry
10px padding. Here, shorthand makes complete sense. Also:
padding: 12px 24px;
margin: 12px 17px 16px 10px;
Here—although I’d question the use of magic numbers—we are still explicitly setting all four sides, so, again, this use of shorthand would still be okay.
The key thing to remember is that shorthand is bad when it’s affecting properties that you don’t actually need to modify.
This kind of action—the inadvertent unsetting of other properties—is particularly problematic in modular and composable systems, where many different classes may be used in conjunction with one another to form more complex composites. Units of code that cannot be combined without collision or conflict are said to lack orthogonality, an important principle in the design of software.
Hi there, I’m Harry Roberts. I am an award-winning Consultant Web Performance Engineer, designer, developer, writer, and speaker from the UK. I write, Tweet, speak, and share code about measuring and improving site-speed. You should hire me.
You can now find me on Mastodon.
I am available for hire to consult, advise, and develop with passionate product teams across the globe.
I specialise in large, product-based projects where performance, scalability, and maintainability are paramount.