The Every Layout Blog

Algorithmic Design

2019-06-14T00:00:00.000Z

The term “system” has two meanings:

A set of principles or procedures to be followed; a method
A set of interconnecting parts, working together

When someone says “design system”, one or other of these meanings may come to mind. An effective design system is both these things together: an exemplification of how to proceed. Weak design systems tend to be either (1) or (2) alone; “do as I say” or “here’s what was done”.

Unfortunately, it’s quite possible to document something within a (nominal) design system without it being a product of systems thinking. Contradiction, duplication, and any number of errors are inevitable unless you take the whole system into account each time you make a contribution. No individual can do this reliably—especially where the extant “system” has already devolved into a morass of exceptions and caveats.

Automating intent

Systematic design is better than acting randomly, but it relies too much on the vigilance of its human contributors. An algorithmic approach to design is the antidote.

Algorithms, like systems, constitute rules devised by humans. It’s just that an algorithm’s rules don’t have to be carried out by a human. It’s dutifully done on their behalf. This means fewer errors and greater consistency, without sacrificing control.

Documentation is to a system what extrapolation is to an algorithm. Algorithms amplify design.

So long as your algorithms are well-defined, they should be able to reason for themselves and handle different contexts and circumstances. Where the rules are ill-defined, you’ll suffer a leaky or malfunctioning system. Like a poorly balanced guitar, it will demand continual tuning.

Algorithmic design for the web

The layout of web content is innately algorithmic, and the web is responsive due largely to the text wrapping algorithm: words automatically wrap according to the available space, ensuring no content is obscured.

We make many of our biggest mistakes as visual designers for the web by insisting on hard coding designs. We break browsers’ layout algorithms by applying fixed positions and dimensions to our content.

Instead, we should be deferential to the underlying algorithms that power CSS, and we should think in terms of algorithms as we extrapolate layouts based on these foundations. We need to be leveraging selector logic, harnessing flow and wrapping behavior, and using calculations to adapt layout to context.

The tools for flexible, robust, and efficient web layout are there. We are just too busy churning out CSS to use them.

Eschewing Shadow DOM

2019-06-14T00:00:00.000Z

Regarding styling, Shadow DOM is really good at one thing: preventing per-component styles from leaking out and affecting other parts of the document.

Unfortunately, Shadow DOM also has a very opinionated way of preventing styles being applied from the parent document. Here is a roundup of the quirks and associated issues I’ve encountered:

Shadow DOM styling issues

Universal styles

Some universal styles (using the * selector) are applied, and others are not. The color property appears to pierce shadow boundaries, but I’ve had no luck with box-sizing. Having to set box-sizing: border-box for each component is redundant.

Inheritance

Document styles are inherited in Shadow DOM. But inheritance only gets you so far, especially since not all properties are inheritable by default anyway. I’ve tried hacking things together with the explicit inherit keyword, but that seems to have no effect.

Using the following is no good, because it forces every node to inherit every property from the parent. If <my-component> had display: flex applied, every one of the component’s descendants would adopt it.

* {
  all: inherit; /* yikes */
}

Slot restrictions

For performance reasons, the ::slotted() selector, which allows you to style the Light DOM content of your component from within your Shadow DOM, only lets you affect child elements and not descendants at depth. This is a bit restrictive. Worse, you cannot seem to use sibling combinators like + or ~. None of the following works:

::slotted(*) + * /* Nope */

::slotted(* + *) /* Nope */

::slotted(*) + ::slotted(*) /* Nope */

Specificity

In making layout components, I like to take a progressive approach: style the component and its Light DOM nodes in my document stylesheet, then enhance with instance-specific styles via props (attributes) in Shadow DOM.

For a component instance that looks like this...

<my-component itemWidth="10rem"></my-component>

...I would apply the itemWidth value in the Shadow DOM using interpolation:

`
<style>
  ::slotted(*) {
    max-width: ${this.itemWidth};
  }
</style>
`;

However, despite being a value specific to my component instance, this will be overridden by the default/fallback styles because they inevitably use a more specific selector:

my-component > * {
  max-width: 30ch;
}

This is fixed with !important, but feels counter-intuitive and hacky:

<style>
  ::slotted(*) {
    max-width: ${this.itemWidth} !important; /* urgh */
  }
</style>

Instance styling without Shadow DOM

For all these reasons, I have developed a different approach to styling my layout components. It’s experimental for web components, but is not unprecedented: Conceptually it is influenced by the sadly defunct scoped CSS spec (as emulated in Vue) and implementations for React like Styled Components. In short: it namespaces and embeds prop-derived instance styles in the document head.

Here’s the full custom element code for a simple component. It lets you use a measure prop to control the max-width of a center-aligned block element.

export default class Center extends HTMLElement {
  constructor() {
    super();
    this.render = () => {
      this.i = `Center-${this.measure}`;
      this.dataset.i = this.i;
      if (!document.getElementById(this.i)) {
        document.head.innerHTML += `
        <style id="${this.i}">
          [data-i="${this.i}"] {
            max-width: ${this.measure};
          }
        </style>
        `;
      }
    };
  }

  get measure() {
    return this.getAttribute('measure') || '65ch';
  }

  set measure(val) {
    return this.setAttribute('measure', val);
  }

  static get observedAttributes() {
    return ['measure'];
  }

  connectedCallback() {
    this.render();
  }

  attributeChangedCallback() {
    this.render();
  }
}

if ('customElements' in window) {
  customElements.define('center-l', Center);
}

On connectedCallback, and each time the measure prop changes, the constructor’s render function is fired. First, the function creates a string based on the new measure value.

this.i = `Center-${this.measure}`;

This identifier is applied to the component instance as a data attribute. Correspondingly, it is used as the id for a <style> element, and within that <style> element using the attribute selector syntax.

this.dataset.i = this.i;
if (!document.getElementById(this.i)) {
  document.head.innerHTML += `
  <style id="${this.i}">
    [data-i="${this.i}"] {
      max-width: ${this.measure};
    }
  </style>
  `;
}

Note the if. A new stylesheet is only added if one with an identifier that matches the current configuration does not already exist. That is, if I were to add a second <center-l> component to my page with the same measure value, it would defer to the existing embedded stylesheet. This keeps DOM operations and bloat to a minimum.

Default values

My measure getter supplies a default value where none exists:

get measure() {
  return this.getAttribute('measure') || '65ch';
}

This is needed so that this.measure does not return undefined. But it does not preclude me from adding a default to my document stylesheet as well — for where JS fails or custom elements are not supported:

center-l {
  margin-left: auto;
  margin-right: auto;
  max-width: 65ch;
}

Performance

Crucially, because Shadow DOM is not involved, it is possible to use a library like JSDOM or headless Chrome to run the code and embedded the necessary (initial) styles on the server. Such tools cannot currently prerender Shadow DOM content (read Server-side rendering web components for more detail).

With the static site generator, Eleventy, I was able to server-side render initial styles using JSDOM and a post-processing “transform” function. Note this required a fork of JSDOM that supports custom elements. Hopefully official custom element support will land soon.

eleventyConfig.addTransform('ssr', function(page) {
  let dom = new JSDOM(page, {
    resources: 'usable',
    runScripts: 'dangerously'
  });
  let document = dom.window.document;
  return '<!DOCTYPE html>\r\n' + document.documentElement.outerHTML;
});

With server-side rendering in place, these kinds of layout-specific components do not require JavaScript to run on the client at all—at least not for initial styling. Rerendering is supported on attributeChangedCallback mostly for in-browser design experimentation, using developer tools.

You Pay (Or Maybe You Don’t)

2019-06-21T00:00:00.000Z

Sometimes people get things spectacularly wrong. So wrong, in fact, that you might suspect they are lying, or someone has been lying to them. On more than one occasion, I’ve been told the political and economic theory of Socialism would insist I worked for free. I’ve had people identify me as a socialist, or leftist, and demand that—in accordance with my political stance—I should give them my books, designs, and other wares for no money whatsoever.

Suffice it to say that Socialism (wherever it is not being deliberately misrepresented) is interested in disseminating rights, protections, and fair compensation for the world’s workers and makers. Instead, it is Capitalism that tries to pay you as little as possible. The less you give for the value you take from the worker, the more excess money (read: capital) you can accumulate.

I hope that clears that up.

Some people can afford to work for nothing: people who have already accumulated lots of capital, for example, or are subsidized by their families. For them, “exposure” alone may be enough motivation. But it’s important they do charge for their work anyway. Why? Because the more people work for free, the less perceived value the work has, and the more likely those who can’t afford to work for fuck all will not be able to secure the money they need to live.

+ + + Always charge. If not for yourself, then for the next person. + + +

Andy and I have put a lot of work and thought into Every Layout. We want it to be the best resource it can be. Naturally, we would like to be paid for the value we are giving you. However, we know that not everyone can afford the things they’d like to have. We’re trying to address this in two ways:

A large selection of free content, including all of the “rudiment” articles that cover the basics of (our take on) contemporary CSS
An honor system, wherein you can claim to be eligible for the full Every Layout for free

What makes you eligible for (2)? If you are currently out of work, you are a full-time student or under 19 years old, you are trying to get your first job as a web developer or designer, or you are an unpaid volunteer for a charitable organization not involved in proselytism: consider yourself a match. Also, if you are the sole person of your ethnicity, gender, or sexual orientation at your company or in your local developer community: we will gift Every Layout to you. If you have a disability that makes accessing equivalent resources difficult, you can have this resource for free. We are trying to make it as accessible as possible.

However: If you are a paying student (including a student or former student of a code bootcamp) the teaching establishment in question should be paying for its teaching materials. If your teacher sends you here for a free copy, let us know. We are happy to finance individuals, but not businesses. We will offer them a bulk license at a discount, so you can get your free Every Layout through them.

It would be logistically and ethically implausible for us to vet, or otherwise judge, if you deserve to have Every Layout without a charge. If you believe you fit into the criteria above, let us know. That’s the honor part.

+ +

Are we suckers? Perhaps, to some. But while you alone decide if you qualify, we decide if you disqualify. That is, if we see you saying or sharing racist, homophobic, transphobic, sexist, or fascist sentiments, or you’re caught engaging in what we consider, in any way, punching down, you get fuck all for free from us.

We figure the kind of people who want our product, and can comfortably afford it, but resent the idea of subsidizing those who can’t afford it, will more than likely disqualify themselves in one way or another. It’s not watertight, but that’s how it’s going to work. Thank you for reading.

+ +

If you think you qualify for the Honour System, head over to and fill out the application form. We carefully consider each application, so would love to hear from you.

Multi-column manipulation

2019-07-20T00:00:00.000Z

Despite predating both Grid and Flexbox, Multi-column Layout represents—at least to me—an even more radical departure from the way we normally do and think about CSS layout. Dividing just one element into a multi-column representation of its contents feels weird, heretical even.

Setting a multi-column context means asking (flow) content to progress, by column, in a horizontal direction. This invokes one of two issues, depending on whether you set a height on the element.

With no set height, there's no limit to the height of the columns. This will result in vertical overflow, and the necessity to scroll down and up the page to read each successive column. Many are likely to find this arduous.

With a set height, columns are forced to spawn in the inline (horizontal) direction, creating horizontal overflow. Setting overflow: auto frames this correctly.

.columns {
  height: 25vh;
  /* ↓ columns defined by width */
  columns: 30ch;
  overflow: auto;
}

However, despite the increasing popularity of scrolling menus and other such patterns harnessing horizontal scrolling, it is still an unconventional interaction paradigm — and unconventional patterns are liable to be misapprehended by users. There are ways to increase perceived affordance, of course—perhaps by adding some custom styling to the scrollbar (-webkit-scrollbar), or providing some overflow-dependent shadows. But this may not be enough.

Quantity-dependent columns

One thing I have been experimenting with is the application of multiple columns in response to content quantity.

Let's say I have a bullet list, and let's assume each bullet point is likely to be relatively short; no more than a sentence. There's no benefit to dividing the list into columns when there are only a few points. But the overall height of the list is shortened (and the chance of the reader being able to see the whole list without scrolling is increased) when a long list is divided into two.

In the following example, the list is split into two columns where there are 5 or more list items.

ol, ul {
  columns: 2;
  column-gap: 1rem;
}

li {
  column-span: all;
}

li:nth-last-child(n+5), 
li:nth-last-child(n+5) ~ * {
  column-span: none;
}

By default, column-span is set to all, meaning each list item ignores the two-column mandate. A quantity query (the final declaration block) then resets column-span to none where 5 or more list items are present. Despite the misleading none value, this means list items will span one of the two columns.

To follow is a live demo. Try opening up developer tools and removing a couple of list items. Note that this behavior is not currently available in Firefox. There is a bug open to implement column-span. Thank you to Erik Wallace for finding it.

+ +

+ + +

+ +

+ + Launch + + (opens new tab) + +

Block direction overflow

As Rachel Andrew has proposed, it would be beneficial to be able to control both the inline and block overflow direction. The support of block overflow would mean we could assume control over both column width and height. So long as the chosen height is no taller than the current viewport, the repetitive vertical scrolling issue described above disappears.

Image caption: Reading down columns no longer necessitates vertical scrolling.

How block overflow direction is implemented and exposed is still up for grabs so, if you have any ideas, you may want to voice them.

My initial thinking is that a column-height property should be supported alongside column-width and column-count. The columns shorthand property would then need to take height as a third parameter.

Currently, columns takes column-width and column-count in any order—presumably because parsing can identify which is a length value and which is just an integer. This becomes more complex with two length parameters, so an expected order for these properties may need to be set. If that expected order is width-before-height, then the following values would be considered valid (where 30ch represents the width, and 25vh represents the height):

.columns {
  columns: 30ch 25vh;
}

.columns {
  columns: 30ch 25vh 3;
}

.columns {
  columns: 30ch 3 25vh;
}

.columns {
  columns: 3 30ch 25vh;
}

It's worth noting that 'hard-coding' a column-count is not likely to be useful in most cases, since both columns and rows are now being dynamically provisioned based on the available space. It's also worth noting that column-width sets an ideal width, not a fixed one, much like flex-basis. This eliminates overlaps and gaps.

The column-gap property injects space between columns. With support of column-height in place, row-gap would have to be supported as well. Although you are probably more familiar with the CSS Grid-specific properties grid-gap, grid-row-gap, and grid-column-gap, Firefox already supports the generic gap, row-gap, and column-gap properties for Flexbox. The intention is to normalize gap across the Grid, Flexbox, and Multi-column modules.

Why you should buy your staff a copy of Every Layout

2019-07-30T00:00:00.000Z

Dear bosses,

You have probably been sent this link by a staff member who would like you to buy them a copy of Every Layout. In this post, I’ll outline some benefits that you, the boss, can enjoy if you invest in your staff’s learning and training by purchasing a copy of Every Layout.

When you understand CSS, you generally make fewer mistakes

So many mistakes—especially with CSS—can be directly attributed to a lack of knowledge, but you only get that knowledge from learning and experience. We share our vast, combined experience in Every Layout to give people a head-start.

CSS is hard, but what we do with Every Layout is demonstrate how keeping things as simple as possible can give your CSS the most power. We leverage the power of the browser and guide it, rather than micro-manage it, for a much more resilient front-end. This approach is completely valid for building a tiny blog, all the way up to a huge design system.

+ + + We leverage the power of the browser and guide it, rather than micro-manage it + + +

We’re convinced that our approach in Every Layout will reduce mistakes. In fact, we know it will, because that approach has served us both very well in our combined experience of over 20 years, working on huge projects and tiny projects alike.

Good CSS knowledge will help to reduce technical debt

CSS is great, but when you over-engineer and over-complicate it, it can get pretty hairy, pretty quickly. A common, knee-jerk response to this conundrum is to employ the use of a CSS-in-JS library or heavy-duty framework, but that is like taking out a Wonga loan to pay off your house.

Technical debt is incredibly expensive, and with modern, all-encompassing web-tooling, the interest rates can be extortionate. In contrast to this, the content we created for Every Layout encourages you to write very powerful layouts, with a tiny, native footprint. These layouts are also portable and interoperable, which means that you can very likely use them across most of your team’s projects. Using these layouts to refactor your existing projects can drastically reduce that high-interest technical debt.

Wrapping up

You get a lot of bang-for-your-buck with Every Layout and it should be a valuable resource for both you and your staff, because their enhanced knowledge will have a positive effect on your business as a whole.

We also try to make the licensing as viable as possible, so if you do want to buy licences for multiple staff members, get in touch and we can work out a bulk discount for you.

If you’re not the boss and need to convince your boss to buy you a copy of Every Layout, send them a link to this post.

Dynamic CSS Components Without JavaScript

2019-10-07T00:00:00.000Z

What is a component? In electronics, it's a discrete device used to affect the behavior of the electricity in a circuit, or electrical system. Electronic components are modular, and are often used in combination to achieve specific values. For example, a number of resistor components of different values might be used in series to produce a desired resistance.

Electronic components take an input, augment it internally, and return a different output. In this respect, the only real conceptual difference between electronic components and web interface components is that the former passes the signal along, and the latter passes it down.

Props

Whether you are using React, Vue, custom elements, or some other component-organized system, inputs tend to be passed to the component via props (properties). The property names/identifiers belong to the component; the values of the properties belong to a containing (ancestor) component and its current state.

A UI component outputs (using a return statement in JavaScript) some UI, and the shape this UI takes is, at least partially, beholden to the values of the props originally passed. Like resitors augment the current, UI components augment the interface.

Rendering

On the web, the UI a component outputs consists of markup/HTML. The structure of that HTML will differ depending on how the current values of its props are interpolated. For example, if a hypothetical users prop consisted of an array of 726 users in its current state, the following render function would output an unordered list of 726 users. Array of 891; list of 891.

const render = () => {
  return `<ul>
  ${prop.users.map(user => `
    <li>${user.name}</li>
  `).join('')}
</ul>`
}

What's neat is that I have a single component, as one module definition, that can be instantiated under differing circumstances and produce different outcomes. For example, I might use the same component just to display logged in users. All that has to change is the input: the value of the users prop.

CSS components

When it comes to CSS, it would probably be beneficial to work in a similar way: leverage a master styling module (née a stylesheet), and provide props just to tweak certain values.

This is the philosophy of the layout primitives that manifest Every Layout's layouts. But the interpolation of prop values is achieved using template literals inside custom element definitions (read: JavaScript). They are only partly “JavaScript independent” because server-side rendering applies the initial styles. Subsequent changes to styling props, on the client, mean re-rendering those styles by manipulating the DOM. This is from the Stack layout:

document.head.innerHTML += `
  <style id="${this.i}">
    [data-i="${this.i}"]${this.recursive ? '' : ' >'} * + * {
      margin-top: ${this.space};
    }

    ${this.splitAfter ? `
      [data-i="${this.i}"]:only-child {
        height: 100%;
      }

      [data-i="${this.i}"] > :nth-child(${this.splitAfter}) {
        margin-bottom: auto;
      }`
      : ''}
  </style>
`.replace(/\s\s+/g, ' ').trim();

(There are reasons why we don't use Shadow DOM.)

Since only JavaScript can affect the prop/attribute that sets the re-render in motion in the first place, one could argue this setup already hangs together as well as can be expected. But what if we could do something similar with just CSS and HTML attribution? It would certainly be less intensive.

Custom properties

Custom properties, unlike static Sass variables, work with the cascade. They can be set globally, but also locally and contextually. Typically, we do this all in a stylesheet file away from our component's HTML. Take the following example, which uses custom properties to manage “separator” symbols applied between adjacent/inline list items.

/* start template */
.separated > * {
  list-style: none;
  display: inline;
}

.separated > * + *::before {
  content: var(--symbol, '→')'\0020';
}
/* end template */

/* start instance */
.separated.hand {
  --symbol: '☞'
}
/* end instance */

The first two of the three declarations is a kind of template (as commented). It takes care of all the gnarly CSS, as well as applying a default value (→). When defining my special hand-based separator component, all I have to do is supply a property representing my chosen symbol. This is analogous to templating HTML using props and JavaScript string interpolation.

Except for one thing: .separated.hand is not an instance of a component, so much as an identifier for a possible/proposed instance of a component. It is not CSS I will necessarily need, and would represent bloat where the class="separated hand" component is retired.

Instead, why don't I just apply the symbol part in the HTML, as needed?

<ul class="separated" style="--symbol: '☞'">
  <li>First separated item</li>
  <li>Second separated item</li>
  <li>etc.</li>
</ul>

This works without any JavaScript (on the client or server). It's just CSS.

But it's also highly efficient for client runs/renders where it is a part of HTML templating (think JSX). Whereas a typical CSS-in-JS solution uses JavaScript interpolation to template a stylesheet and append it to the DOM, all that has to change here is the symbol itself. The CSS “module” will already be loaded and, since it doesn't need to be manipulated directly, can also be cached.

return `
  <ul class="separated" style="--symbol: {symbol}">
    <li>First separated item</li>
    <li>Second separated item</li>
    <li>Setc.</li>
  </ul>
`;

Moreover, you can affect the props directly in your browser's dev tools, by editing the style property's HTML. Because we felt this would be a handy feature for exploring and prototyping with the Every Layout layouts, we built this feature into the custom elements. We had to specify getters and setters, and observe prop changes with the attributeChangedCallback. None of that is necessary when the props are just CSS, as in the method proposed here.

CSS is reactive by nature, in a way JavaScript can only aspire to be.

Multiple properties

Of course, you can use multiple properties if you need. Maybe I'd like to display my list as a CSS Grid and control the grid-template-columns and grid-gap properties…

<ul class="grid" style="--columns: 20ch 1fr 50px; --gap: 2rem">
  <li>First separated item</li>
  <li>Second separated item</li>
  <li>etc.</li>
</ul>

Again, the basic CSS grid CSS file (including display: grid, align-items: center and whatever else is constant) can be cached and reused, without having to forego the props-as-inputs authoring model. The stylesheet acts just like a JavaScript module for a function, accepting (in this example) two arguments.

Perhaps you'd like to pass multiple props around in objects? Because that's easier to read and work with in JS? No problem: a small mapping function can convert from an object into a custom property style string with ease:

const toCustomProps = obj => {
  return Object.entries(obj).map(entry => {
    return `--${entry[0]}:${entry[1]};`
  }).join('')
}

const styleProps = {
  columns: '20ch 1fr 50px',
  gap: '20rem'
}

let styleString = toCustomProps(styleProps)
// → '--columns:20ch 1fr 50px;--gap:20rem;'

Since we are only dealing with custom properties, for which we can choose any name, we don't have to worry about things like the difference between CSS's background-color and JavaScript's equivalent backgroundColor.

Portability

In many ways, the CSS components I'm proposing are like Every Layout's custom element layout primitives. But because they use class names instead of element definitions, they are more portable.

They can be applied to any element or component, inluding any semantic HTML. One of the shortcomings of custom elements is that they are unsemantic by default, meaning you have to bolt on semantics using ARIA. In previous examples, I used <ul> and <li>. Using custom elements instead, I'd have to apply the list and listitem roles.

<my-list role="list">
  <my-listitem role="listitem">...</my-listitem>
  <my-listitem role="listitem">...</my-listitem>
  <my-listitem role="listitem">...</my-listitem>
</my-list>

Limitations

I think there's a lot of potential in this approach. I like how it gives granular control over styling without encouraging the proliferation of either manually-written classes or JavaScript generated selectors.

The glaring, though not necessarily deal-breaking, limitation is that only CSS property values can be affected. I can't interpolate custom properties into CSS selectors. The ability to write selectors dynamically, just in CSS, would make for an interesting feature.

.stripes > :nth-child(var(--pattern, 'even')) {
  background-color: grey;
}

.stripes.odd {
  --pattern: 'odd';
}