CSS shorthands: should you write them?

András Tóth - May 30 '22 - - Dev Community

(What is a CSS shorthand? Example is: flex: 0 1 10%; it is an abbreviation of multiple CSS declarations)

Short answer

No.

Also please do not teach them for beginners as "a nice thing to do". It sets them a really bad example.

The long explanation

There are rules of clean coding that shorthands violate:

Mental mapping

Mental mapping is when you see something that is not obvious, therefore mentally you have to maintain an accurate "definition table" to remember what the thing was. It is a wasted mental effort and since memory plays a huge role here, mentally mapping would make you suffer from typical phenomena associated with memory. For instance if you learned and used several competing standards for the mentally mapped thing, your chance of failure is much higher than if you only know one.

It is OK not to be an organic parser.

Magic location is a variant of mental mapping, where you have to remember the exact location and its meaning accurately to resolve the abbrevation.

For instance if you see this function call:

updateUser(12, 34, 33, 1000, 0, null, 'yes');
Enter fullscreen mode Exit fullscreen mode

you would need to recall how each parameter was called and their roles for every position. Sounds like madness to me... 😐

CSS Example

Let's analyze flex: 0 1 10%, flex: 0 10% and flex: 0 10!

In the first one, the first number is a shorthand for flex-grow, the second number is flex-shrink and the third is flex-basis. If you rarely write CSS, you will be hard pressed to remember it. At the moment of writing this I needed to go back to the documentation to check it again if it was not the other way around... And I write CSS weekly at least once.

Even worse, if you finally remember that the second number is flex-shrink that's not sadly always true.

In the second example when % sign was used it will mean: flex: <flex-grow> <flex-basis> but in the last example it will be flex: <flex-grow> <flex-shrink>. You see? Even the meaning of the location is conditional!

The alternative

After struggling with these for many years I decided to drop shorthands except for the absolute basics (like padding, but sometimes I write that out fully when let's say only the bottom is not needed.)

Does it really hurt to write like this?

.thing {
  flex-shrink: 0;
  flex-grow: 1;
  flex-basis: 10%;
}

/* instead of this... */
.other-thing {
  padding: 13px 24px 0 24px;
}

/* this? */
.other-thing {
  padding-top: 13px;
  padding-right: 24px;
  padding-left: 24px;
}
Enter fullscreen mode Exit fullscreen mode

Does size matter?

If you are concerned about size of the CSS bundle use a minifier and employ smart strategies: if you redefine the same thing over and over instead of using some kind of semantics the bundle will just grow. If you use a third party template like bootstrap you can also use scss or less to import only the declarations you are actually using in your code.

So the size issue can really be solved by tools.

And we humans can spend the time on fixing problems instead of figuring out how previous solutions worked.

Worried about typing a lot?

This is going to be a harsh statement, but it is important to give you an emotional impact:

If you are concerned about the amount of characters you need to type, maybe you should not work in teams.

Much of my work is done so other team members can understand my code deeper and quicker. It saves time for them, or for me a couple of weeks later or in the end for the company. As I said before, we are not parsers, our mind is full of remnants of other paradigms, other standards, and lastly there are simply just other developers who are going to be guests in your codebase or in frontend development and you cannot really demand them to remember all these things.

So, let's leave the shorthands for the machines and let's write code for humans! 😊

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .