
The urge to explain something visually never leaves my mind, the fight against enthropy never actually ends.
No one ever wins, but maybe I can help change a few trajectories with a more open approach.

Starting from scratch, leaving things behind, focusing on things that matter, rebuilding live.

- [x] New domain. It's me.
- [X] Nothing tops the chocolate theme of mint, but [Fathom](https://usefathom.com/ref/VDNDJG) is OK.
- [x] Fix the FOUC. [NextJS](https://nextjs.org) is life.
- [x] Design. Going for the sane-brutalist.
- [x] Writings page and [RSS](/rss.xml).
- [x] Markdown CSS needs tweaking.
- [ ] Cleanup and republish old posts.
- [ ] About page.
- [ ] Stacks page.
- [ ] Projects page.
- [ ] Open source the glued engine.


From scratch


CSS is a second class citizen in software, designed _only_ to style and present content: Developers tend to (and love to) be annoyed by it.

CSS has a stain, it has quirks and implementation details that change over time. It's growing up slowly, the working group is hard to follow, and new functionality takes time to be up to date with.

### It's a hassle, I love it.

In this series, I'll collect tips'n things that I think could make a difference. Bear with me.

---

There is always a reason CSS gets messy, but let's not jump the shark yet, start with the basics: **Order**. A familiar syntax, you know the class, it does what it does, this code will render a button.

This is how ~~most~~ a lot people write CSS.

```css
.button {
	color: white;
	background: #3f55aa;
	border-radius: 0.5rem;
	border: 1px solid white;
	font-size: 1rem;
	margin: 1rem 0;
	display: inline-flex;
	transition: opacity 100ms ease;
	padding: 0 0.5rem;
	font-family: sans-serif;
	text-transform: uppercase;
	position: relative;
	z-index: 99900001;
}
```

When I see something like this, here is what I think: _Sigh. A button._ And this is what I'd like to know instead: _Where it is, what it does, how it looks, and can I safely modify it?_

Is this sustainable? Can this waterfall approach scale in any way? Absolutely not. Ok then, let's pretend we care and order properties from a-z.

```css
.button {
	background: #3f55aa;
	border-radius: 0.5rem;
	border: 1px solid white;
	color: white;
	display: inline-flex;
	font-family: sans-serif;
	font-size: 1rem;
	margin: 1rem 0;
	padding: 0 0.5rem;
	position: relative;
	text-transform: uppercase;
	transition: opacity 100ms ease;
	z-index: 99900001;
}`
```

Is this better? It feels better, scales better, but without further structuring it's still a mess. I found the following practice to be the closest to how design works.

Hint: yes, it was design all along.

```css
.button {
	position: relative;
	z-index: 99900001;

	display: inline-flex;
	margin: 1rem 0;
	padding: 0 0.5rem;

	background: #3f55aa;
	border-radius: 0.5rem;
	border: 1px solid white;
	color: white;
	transition: opacity 100ms ease;

	font-family: sans-serif;
	font-size: 1rem;
	text-transform: uppercase;
}
```

Now we're talking. From a quick glance, you:

- know this element is relative positioned
- have the explicit line to put a new property
- can remove that margin property that doesn't belong here

### It's accessible.

The order I usually advise for is the following (you can set this up in stylelint):

- **Layout**: The position of the element in space. Eg.: \`position\`, \`top\`, \`z-index\`.
- **Box**: The element itself. Eg.: \`display\`, \`overflow\`, \`box-sizing\`.
- **Visual**: Design of the element. Eg.: \`color\`, \`border\`, \`background\`.
- **Type**: Typesetting of the element. Eg.: \`font-family\`, \`text-transform\`.

Picking up this simple system is easy, and it's a step that could save you from drowning in product debt. Now, please go ahead and at me ([@pyx](https://twitter.com/pyx)) asking where to put that \`--webkit\` prefix you must include manually.

---

_Edit:_ Adding some actual resources to go with the theory. My approach initially came from exporting and grouping design assets; influenced by the principles of [idiomatic CSS](https://github.com/necolas/idiomatic-css).

Others:

- [stylelint-order](https://github.com/hudochenkov/stylelint-order) plugin.
- @mdo's [Code Guide](http://codeguide.co/#css-declaration-order) has a somewhat similar approach.
- [SMACSS](https://smacss.com/book/categorizing) also has a section about ordering.
- [sass-lint](https://github.com/sasstools/sass-lint/blob/master/docs/rules/property-sort-order.md) could help you out with the ordering.

Keys to maintainable CSS: Order


Custom properties (or CSS variables) are not a new feature, they are in the CSS spec since 2014, but browser vendors lagged behind. Firefox adopted early, Safari and Chrome in 2016, and in late 2017 even Edge implemented it fully, giving it 88% global coverage with IE and Blackberry’s browser pulling back the number. In 2018 it is safe to say that it’s ready for the modern web.

Choosing the native implementation over a rigid processor gives you much more than a simpler development process. Custom properties are live, they can be changed based on media queries, element scope or with plain javascript. When a CSS variable changes, the browser repaints the already rendered view without any additional push. It’s low-level and fast.

The ability to iterate and change things without unnecessary layers of abstractions enables you to ship faster and build a better product.

---

One of the single best feature of CSS processors is variables. Having the ability to declare once and reuse the variable across your project should not be optional in any system. Using a pre-processor like SASS or LESS gives you at least one extra build step, which can be a pain if you just want to build a thing fast. CSS has come a long way since the dark days of table hacks, let’s look into one of the most useful one: Custom Properties.

We'll start with a simple example.

```css
:root {
	--color-red: #fc4752;
}

.site-navigation {
	background-color: var(--color-red);
}

.site-footer {
	color: var(--color-red);
}
```

The :root pseudo selector targets the highest-level parent element in the DOM, giving all elements access to --color-red. Yes, CSS variables definition should start with --, and you can access them anywhere with var(). Well, anywhere, that is cascaded under our :root selector.

With var() you can also define a fallback value, which will be used if the given variable is unreachable or non-existent for the class.

```css
.site-navigation {
	background-color: var(--color-red, red);
}
```

Values are inherited from the DOM, which means you can make them more specific.

```css
:root {
	--color: red;
}

.site-navigation {
	--color: green;

	background-color: var(--color);
}

.site-footer {
	color: var(--color);
}
```

Every var(--color) is red, except every var(--color) under site-navigation. Generally speaking it’s not a good practice to overwrite an already defined value, but there are cases when a scoped value is the most adequate solution.

These are the basics, but you can do so much more. Another great example is changing layout based on viewport size.

```css
:root {
	--color-red: #fc4752;
	--flex-layout: row;
}

@media (max-width: 640px) {
	:root {
		--flex-layout: column;
	}
}

.site-navigation {
	display: flex;
	flex-direction: var(--flex-layout, row);

	background-color: var(--color-red, red);
}

.site-footer {
	color: var(--color-red);
}
```

Under 640px the media query triggers, changing the flex direction to column on site-navigation class, making it’s content vertical (column) instead of the default horizontal (row). In this example, because of the default variable given to site-navigation, you don’t even need the initial :root definition of --flex-layout, it will go straight to row.

This is cool, but not all fun and games just yet. For instance, since the media query is not an element, the breakpoint value cannot come from a custom property. Although CSS Working Group have a draft of using env() for queries, vendor implementation and proper support is probably years from today.

That’s ok. We will stick to what we have now. One of the more advanced use case for custom properties is switching themes. You can define a base theme, build your website around it, and just switch it out with the browser doing the heavy lifting. And it’s not even heavy.

Think about Twitter night mode, but without actually switching the CSS (I see you).

```
<main>
	<nav class="site-navigation">
		<div>I love interwebs</div>
	</nav>
	<div class="site-footer">
		<label for="color-picker">Change color</label>
		<input type="color" id="color-picker" />
	</div>
	<style>
		:root {
			--color: #fc4752;
		}

		body {
			margin: 0;
			padding: 0;
		}

		main {
			display: flex;
			flex-direction: column;
			justify-content: space-between;
			height: 100vh;
		}

		.site-navigation,
		.site-footer {
			padding: 12px;
		}

		.site-navigation {
			background-color: var(--color, red);
		}

		.site-footer {
			color: var(--color);
		}
	</style>
	<script>
		var colorPicker = document.querySelector('#color-picker')

		colorPicker.addEventListener('change', function() {
			document.documentElement.style.setProperty('--color', this.value)
		})
	</script>
</main>
```

Input color’s picked value replaces the document’s --color value, making the change without a hitch. You can play with blend modes, alpha channel colors or pngs, the possibilities are endless and fun.

Now, with your future proof CSS in place, which depends on no third party developer, using only custom properties there is a good chance you are covered and even good to go production.

But what if you want something other than variables in your code, let's say CSS modules maybe? As of today, for existing CSS features like modules or nesting, you couldn’t spare the extra build step any longer, but you can implement it with the sweet promise of not having to rewrite code when vendors catch up with the spec.

Instead of refactoring your CSS every time you want to improve your output, you should write your code in a specification aligned way in the first place. This is the main difference between pre- and post-processors. A pre-processor actually writes the CSS for you (basically, from a text file), while a post-processor aligns your already valid CSS for more browser support, latter giving you more flexibility in the process.

Using the native method always beats the workaround, and having the working knowledge of future technologies is the best bet you can have going forward learning CSS.

---

This article was also published under [Net Magazine](https://www.creativebloq.com/how-to/an-introduction-to-css-custom-properties) / issue 306.

By writing valid CSS and using custom properties you can future-proof your code; here's how to get started.

An introduction to CSS custom properties


#### A design system is more than a collection of reusable elements. It holds together UI pattern libraries, compatible component code, basic interaction models; all documented and supported by brand guidelines.

Building such a robust system takes time and dedication from your team. It sure will benefit you in the long run, but only if there is a long run. Since there is no _done_ state, it is hard to draw a line. You have to nurture it as your product (and technology) grows, while investing just the right amount of time.

In this article I'll try to provide some actionable tips that you can safely start with.

## Where to start?

Let's assume you have a prototype or an MVP. Take the elements you **use multiple times**, separate them. Are they abstracted enough to be used elsewhere? Remove the unnecessary bits.

Does this newly separated element have any unique interaction? Can you remove it? You don't want anti-patterns that you are not aware of.

Are there types or buttons? Are they aligned the same way on every instance of your components? Get it together. I'm all for smart solutions, but at this stage you only need to aim for **consistency across your product**.

Cover the states of this component. Although not all element can possible yield a Done state, this task still can be time consuming, and might not worth it at first. So, go with the easy ones: **Loading, Empty, Correct, Failed**. Later you should also cover the missing ones: Incorrect, Some data, Too much data, Done.

People use mobile a lot. Make your apps responsive and - at the very least - **usable on all medium**.

Separate the colors, use named variables. Red means nothing; Dark Cherry Red of Awesome Inc. on the other hand does ring a bell. Too many shades of red? Canonize. Make sure the color combinations pass the **color contrast test**, you want your content to be accessible.

Cleanup the code, agree on a **coding style**. Make your elements pass said style.

In an optimal word, all of these would be documented, but let's not kid ourselves. **Document parts** you'll be using the most. Colors and type, extend it later. In order to any of this to be beneficial, you also have to **communicate** all of the above, as well as making it accessible by anyone at any given time.

## Ok, but why?

The purpose of a design system is to help you ship faster. Removing bad patterns, and forced, complicated interaction will help you **prototype and iterate** faster, while keeping your product consistent and useful.

A single source of truth - of any level - gives you clarity, and drives the **common understanding** of a problem you try to solve.

How much design system do you really need, and where to start building one.

How to start a design system


No secret that design systems often use the number 8 as base value for scaling their patterns. Github's own [primer](http://primercss.io/) or Google's [material design](https://material.io/) are good examples for this practice. Using 2x2x2 became the rule of thumb. There are a lot of articles about how to implement such a system (duh), but not much on the why.

Some digging and rambling below.

## It's because it scales, dummy

One of the most _visible_ parts of a design system is spacing. Spacings are the building blocks of components and layouts. A small gap is not just a self-serving visual key, it can define meaning, strengthen a user-flow or establish relationship between elements. For a good user experience, pages cannot jump around visually, there should be peace among elements. **Having fixed spacing helps you keep your design steady.**

What happens if you just use an 5 point base for spacings?
Some user will zoom in, others would like to have crazy retina screens.

110%, 125%, 150% 175%, 200%.
If you only consider spacing — this might just work.

## Typography

### Font sizes

Things were great when only metal pushed ink into paper, but when we turned on computer screens, the initial joy we had faded quickly. Operating systems converted from point based system to pixels, shit started to hit the fan.

| OS      | point size | pixel size | resolution |
| ------- | ---------- | ---------- | ---------- |
| MacOS   | 12pt       | 12px       | 72 ppi     |
| Windows | 12pt       | 16px       | 96 ppi     |

> Throughout the late 1990s and early 2000s, websites had body text anywhere between **9–14px**. For a while, [designers thought 16px was too large](https://books.google.com/books?id=zZ4K3-vdN3oC&pg=PT345&dq=designers+think+that+16px+is+too+large&hl=en&sa=X&ved=0ahUKEwjz0NOH16XPAhXFVh4KHYxoA5QQ6AEIHjAA#v=onepage&q=designers%20think%20that%2016px%20is%20too%20large&f=false) because they were used to the 12pt (**12px**) default on their Macs. [2]

### Baselines

In order to communicate with your audience, emphasize, interact, spark interest; a good system should define a scale for type. Being as basic as spacing or colors, font usage alone can tell a tousand stories.

One crucial, ofter overlooked part of a typescale is the baseline. Baseline essentially is vertical spacing, determined by the line-height property of your body text. [1]

## Whole numbers

Now, with our _pica_-s converted to pixels, we can even do some math. Line heights usually moves between 120-180% of the font pixel size. _Of course thats not true. There are exceptions, special fonts and use-cases._ [3]

| multiplier | 100% | 125% | 150% | 175% |
| ---------- | ---- | ---- | ---- | ---- |
| 1.5        | 12   | 15   | 18   | 21   |
| 1.75       | 14   | 17.5 | 21   | 24.5 |
| 2          | 16   | 20   | 24   | 28   |
| 2.5        | 20   | 25   | 30   | 35   |
| 3          | 24   | 30   | 36   | 42   |
| 3.5        | 28   | 35   | 42   | 49   |
| 4          | 32   | 40   | 48   | 56   |
| 4.5        | 36   | 45   | 54   | 63   |
| 5          | 40   | 50   | 60   | 70   |

Little to no fractioned number in a given composit comes visual rhythm. Product interactions and intentions of the brand will be in sync. **Interoperable parts will less likely to feel off.**

There is no holy grail in scaling alone — all of this only mean you have to deal with scaling to keep a system viable.

---

[1] Not going into details here, but I can't recommend [A guide to vertical rhythm](https://iamsteve.me/blog/entry/a-guide-to-vertical-rhythm) enough.
[2] Read more about the history of font sizes here: [Your Body Text Is Too Small](https://blog.usejournal.com/your-body-text-is-too-small-5e02d36dc902), [Point (typography)](<https://en.wikipedia.org/wiki/Point_(typography)>).
[3] Slightly updated table from @[broccolini](https://twitter.com/broccolini)'s [Design Systems: when and how much?](https://speakerdeck.com/broccolini/design-systems-when-and-how-much) talk.

---

_Something to add? Tweet me [@pyx](https://twitter.com/pyx)._

Design systems with 8 point base


#### Whether you are iterating on a prototype for a client, updating your design portfolio, or building a large scale web product in React, you are facing the same fundamental problems. You want to increase your velocity, write less code, while keeping visual and interactional consistency.

**The most valuable promise of immutability in atomic design is that it eliminates unwanted side effects.** With single-state, easy to understand helper classes in hand, you are forced to think functionally.

An atomic css library instantly grants you a system that can be scaled, extended and build on.

[Fractures](https://fractures.space) is a small, atomic CSS library built by extensibility and accessibility in mind. My main goal was that it should leave the visible UI untouched, enabling other systems to adopt it. Also I wanted to avoid any code pollution, so the whole library is under 3kb, nothing more than the bare minimum. And for good reasons. Besides speed, developer happiness is important even at atomic levels, so the classes are designed as easy-to-remember as possible.

In fractures, utility classes gets their name by the plain function they do, reducing the effort needed to apprehend their purpose. For example, just like CSS grid layout have grid-gap, fractures introduced flex-gap, which works the same way, but on a single dimensional grid. As CSS working group is about to add [row-gap and column-gap](https://twitter.com/rachelandrew/status/893450430512017408) to flex, this function will just work, keeping that immutable promise we oath to before.

![](/images/2017/fractures.svg)

In larger scale applications, having an atomic CSS library is only the beginning. For sustainable product/development costs, you have to invest in your own design system. Without defined constraints, things will soon start to fall apart — that is normal, and is how it should be. It is hard to resist the urge, to carve things into stones, but premature optimization in reality is suboptimal for every system.

### Implement reusable elements only when you’ll actually reuse them.

> Either you’re rolling your own internal version, or picking a library for your specific needs, investing small at the right time is important. Thinking and working in systems keeps developers, designers and your users happy.

Writing functional CSS is not a new concept, there are quite few stable atomic libraries you can choose from if you find fractures a bit too spartan. One of the oldest and greatest is [tachyons](https://github.com/tachyons-css/tachyons), with responsive features, and with the most active user base. For React, there is [rebass](https://github.com/jxnblk/rebass), with similarly wide scoped features.
A few great resources that I think you'll find useful:

- [Atomic Design](http://atomicdesign.bradfrost.com/) _is a must read by Brad Frost._
- [Functional Programming, CSS, and your sanity](http://www.jon.gold/2015/07/functional-css/) _An article about the beauties of functional programming by Jon Gold_
- [Cooking with Design Systems](http://danmall.me/articles/cooking-with-design-systems/) _Thoughts about a Design System by Dan Mall_
- [Intro to CSS Grid](http://labs.jensimmons.com/) _Grid experiments by Jen Simmons_
- [Grid by Example](https://gridbyexample.com/) _Everything you need to learn CSS Grid Layout by Rachel Andrew_


Write CSS with manually maintained immutability. WCGW

I'm Chris–designer and engineer, builder of software and systems.

I'm Chris
–designer and engineer, builder of software and systems.