CSS shorthands: should you write them?
Tags: css
Published: 2022-05-30 16:09:20

(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:
```javascript
updateUser(12, 34, 33, 1000, 0, null, 'yes');
```

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?
```css
.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;
}
```

### 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! 😊