
After almost 5 years after I published [Fractures 1](https://pyx.sh/post/atomic-css-with-fractures), it's time to revisit idea of having a fathomable atomic CSS library. Building software for the web is more complicated than ever, CSS is getting a lot of new feature, yet unique designs and accessible applications are hard to find.

Wouldn't it be nice to have a reliable utility box with reasonable defaults. Maybe people need a solid tool, and **not total autonomy on every single thing imaginable**.

[Fractures](https://fractures.dev/) does not try to replace your current system. Instead it provides a solid, immutable base to build on top of. The point is **not to stop writing CSS**, but to keep your custom CSS maintainable. It aims to be the baseline of a system to enable fast moving teams to build better UIs.

The core principles are the same.

-   Atomic
-   Framework agnostic
-   No UI
-   Fast in every way
-   Manageable cognitive load
-   Small footprint

Fractures is [open source](http://github.com/fractures/fractures). It includes a simple reset, responsive and hover helpers, color system, and various, immutable utility to make life easier.

It can be adopted incrementally:

```css
import '@fractures/css/dist/fractures.reset.css'
import '@fractures/css/dist/fractures.config.css'
import '@fractures/css/dist/set/flex.css'
```

or as the default 29kb: (see [fractures-next-ts](https://github.com/fractures/fractures/tree/master/packages/fractures-examples/fractures-next-ts))

```css
import '@fractures/css'
```

there is also a work in progress [React Pattern Library](https://ui.fractures.dev) built on top of `@fractures/css`, aiming to mix fracture principles with a more human design. This is an early draft, you can [DM](http://twitter.com/pyx) me for an invite.

👋

Introducing Fractures 2.0


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 could make a difference.

---

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 is it, 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 relatively 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 is the following:

- **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. 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`. CSS variables definition 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 as you go down.

```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).

```html
<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 picked value replaces the documents `--color` value, making the change without a blink. You can play with blend modes, alpha channel colors or pngs, the possibilities are endless. 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.

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 in Net Magazine / issue 306.

By writing valid CSS and using custom properties you can future-proof your code

An introduction to CSS custom properties


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 upon.

[Fractures](https://fractures.dev) is a small, atomic CSS library built with extensibility and accessibility in mind. My main goal was that it should leave the visible UI untouched, enabling other systems to adopt it. I also wanted to avoid global pollution, 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 are getting 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 you might 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 immutable, atomic, utility classes