
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<sup>1</sup>, leaving things behind, focusing on things that matter, rebuilding live.

- [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)<sup>1</sup> 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


#### 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.dev) 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.

![Logo of Fractures](/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