The fact that a single set of standards — HTML, CSS, and JavaScript — has been refined over decades to grow impressively more inclusive, to support so many new contexts, all while being entirely backwards compatible, is remarkable. A feature can take endless forms when it reaches the end user, and trying to work with that unpredictability, along the grain, is what I like about my work.

This perspective is something I've grown into over time. Early in my career, I was more interested in ambitious prototypes and funky experiments (“look what I made!”) but these days I prefer using the platform as it was designed, leveraging its strengths. There’s often a straightforward, well-supported way to solve a problem, and I enjoy finding it. It rewards curiosity, precision, and care.

Allowing that curiosity to take the lead, I’ve spent the last decade working at the intersection of design and engineering. To make something resilient, accessible, and fast, you have to think in systems and care about details. And to shape those systems meaningfully, you have to understand users, flows, and interface patterns.

My official titles have leaned towards engineering, but much of my day-to-day work has lived near the edge of product design. At Fora Health, working with vulnerable user groups taught me to notice the emotional impact of my design choices. Designing in problem spaces like clinical depression and dementia, I learned firsthand how even a single misplaced word can have a dramatic effect on how someone feels walking away from an interaction — a lesson in empathy that I've found applicable in every design problem I've faced since.

At Griffin, I led the design and development of a design system powering complex banking apps, marketing sites and internal tools. But in parallel, I continued designing on a higher level for product areas like 2FA, billing and payment operations. I was constantly zooming in and back out, across the pace layers of process, from the outer orbits of innovation to the quality of individual interactions at the core.

Changing contexts like this daily helped shape my philosophy towards design engineering as a discipline. Providing teams with a shared UI language is only the baseline. At a higher level, I've come to see it as firmly rooted in empowerment and enablement — lowering the barrier to quality for everyone involved in building the product, through education, inclusion, and making the right thing the easiest thing to do.

Design systems are one tool — a robust UI library will scale quality. But alongside that, accurate developer documentation will foster adoption, higher-level design guidelines will create trust, working with product designers and PMs spurs innovation, and fixing papercuts will demonstrate care, while setting the bar high. As one founder explained his vision to me, it's as much about guiding designers towards excellent code as it is about guiding other engineers towards UI excellence — and there is so much more to that than design system ownership.

In practice, this kind of work can take many forms. It could mean maintaining a record of design decisions. Sometimes it's providing an alternative declarative API in an otherwise compound component¹. Or formatting design guidelines as flowcharts to better support complex decision-making. Adding automated accessibility checks to the testing suite. Publicly celebrating papercuts fixed. Refining the build pipeline to better support theming. Other times it's pairing with other engineers or joining RFC discussions to keep design infrastructure grounded in the realities of how teams actually work day to day. And calling it infrastructure matters — it's not the layer on top, it's what gets built with.

This kind of glue work helps make quality the default outcome in teams without enough design-focused engineers to go around. And for a solo UI engineer in a mostly backend-leaning team — as I've found myself in many past roles — the need for this connective tissue ends up shaping much of the work.

But I still get enormous pleasure from the craft itself, and I’ve missed working closely with likeminded engineers who enjoy refining the details that make a UI feel solid. I've recently been going through a preview of Rauno Freiberg's upcoming Devouring Details interaction design course, and it's been a welcome reminder of how much joy there is in chasing quality at the level of individual interactions² — not just for the polish, but for the confidence this instils that the same quality is also present in the parts of the product that the user can't see.

Paco Coursey captures it perfectly:

Animate those icons. Brand that scrollbar. Polish that :active state. Load a single typeface glyph to render the world’s best ampersand. Make it fast. Make it accessible. Add keyboard shortcuts. Add tooltips. Animate the transition between two open tooltips. Manually measure text and avoid line wrapping widows. Design favicons that reflect app state. Convert internal URLs to rich previews. […] Design a whole new stylesheet for printing. Design a whole new page for mobile. Dynamically generate video thumbnails and use them in a custom video player. Optimize your re-renders.

It’s the sort of work where aesthetics, accessibility, motion, and psychology meet frontend performance and CSS craft, and where I slip into flow most easily.

Working with thoughtful, principled engineers and talented designers over the years, I've picked up enough from both to navigate the intersection, acting as glue when needed. The pull between disciplines often feels like a tension — a choice on which edge of the split I want to fall on. But the balancing act itself is also what keeps me attentive, and the work rewarding.

I'm taking this mindset to Plain, and I'm curious to see how the lines continue shifting in a new context — especially now, as AI is redefining in real time how we design and build for the web. Methods change, but the results will depend on the same core principles. There's plenty still to work out!

Griffin UI Design

A bird's-eye view of the visual design work I produced for the family of API-first banking products while at Griffin

Design guidelines for a Table component

A set of interactive design guidelines that I wrote for the Table component in Griffin's design system

Fora Health UI Design

A bird's-eye view of the visual UI design I produced for the Fora Health app during my time at Ctrl Group

Schematics: A Love Story

An animated a collection of diagrams from a visual poetry book by Julian Hibbard

Tenfold

A number puzzle game for iOS  

At Griffin, I led the design and build of a multi-theme design system powering two complex banking apps and several websites.

As a generalist designer/developer, my design work spanned from higher-level product design (working on features such as billing, Open Banking, and API security), low-level UI polish, producing public-facing marketing material, and writing interactive design guidelines.¹

In most of the below examples, I produced both the design and the implementation. All but a few made their way to production.

Let's look at where this comes from, why redundant HTML should be avoided in the first place, and how to do so without sacrificing the neat separation of concerns that helps to create the shared language between design and development.

Note: The examples in this post will be React-specific, but the core idea extends to most JS-based component libraries.¹

Consider a Card component with a title and optional description:

<Card>
  <Stack spacing="medium">
    <Heading>Card title</Heading>

    {description &&
      <Text>{description}</Text>}
  </Stack>
</Card>

From the component library design point of view, this makes sense:

• Card is responsible for visually framing the component.
• Stack is responsible for the spacing between the heading and description.

Let's look at the HTML this produces. A simplified version might be something like this:

<style type="text/css">
  .card {
    border: 1px solid silver;
  }

  .stack {
    display: flex;
    flex-direction: column;
    gap: 1rem;
  }
</style>

<div class="card">
  <div class="stack">
    <h2>Card title</h2>
    <p>Description</p>
  </div>
</div>

Strictly speaking, you don't need two wrapper divs to achieve the intended look. If you'd never been “tainted” with the design system mindset and instead built this bit of UI using plain HTML and CSS, I'd be willing to bet you'd instinctively combine the styles for the card frame and spacing between children into a single class². The card description could be included or omitted without any impact on the markup:

<style type="text/css">
  .card {
    display: flex;
    flex-direction: column;
    gap: 1rem;
    border: 1px solid silver;
  }
</style>

<div class="card">
  <h2>Card title</h2>
  <p>Description</p>
</div>

<div class="card">
  <h1>Card title</h1>
</div>

We have lost the redundant wrapper. But we have also lost the neatly separated areas of responsibility for the card frame and element spacing. The importance of neither should be overlooked, but satisfying both requires us to be deliberate in how we design our component APIs.

When you're the one authoring a component, you have a level of control over the markup and styling that lets you keep bloat to a minimum. The onus cannot be on the consumer of your library to make these same optimisations at the inter-component level, because they probably won't. Why not?

• Semantics and accessibility are usually handled for you in design system components, so it can be easy to forget that this doesn't extend to page-level (inter-component) code.
• While minimising markup bloat isn't particularly tricky, it can result in a fair amount of boilerplate.

Creating context-aware components in a way that consumers can ignore inter-component markup altogether is unrealistic. For now, we cannot bundle good page-level markup hygiene free into our design systems, but we should at the least make working towards it convenient.

I'd like to cover a few ways that component APIs can be extended to make the underlying markup more flexible. But before that, a sidebar on why bloated HTML should sound alarm bells in the first place. Should we be worried about div soup at all in 2023?

Why avoid extra wrapper elements?

1. Bloated HTML hurts performance

Redundant wrapper elements are a form of bloated HTML, and bloated HTML can hurt performance, both during page load (resource size) and runtime (costly layout reflows and element querying).

We obsessively optimise when it comes to scripts, styles, and other resources; interestingly, that doesn't always apply to HTML. In the case of single-page apps, it may feel like you stand to gain more in performance if you focus on JavaScript. In the case of server-rendered, non-interactive sites, some people doubt that the performance impact of a large DOM is noticeable.

We also lack the required tooling: according to Jens Meiert, not enough HTML minifiers prune optional HTML tags and default attributes³. When it comes specifically to unneeded wrapper elements, tooling wouldn't help us anyway (you would need a pretty sophisticated analysis of the associated styling to determine if an element can really be omitted).

2. Redundant elements can create problems with accessibility

Our markup needs to be semantic; an extra div here and there doesn't take anything away from that. But a misplaced extra element can make your carefully selected semantic tags useless.

This happens mainly with elements that have strict rules about containment or placement. For example:

• A legend must appear as the first child of fieldset.
• A figcaption must appear as the first or last child of figure. 
• A li must appear as a direct child of either ul, ol or menu.
• dt and dd must both appear as direct children of dl⁴

Design system components with a strict separation of concerns can easily break this⁵:

<ul>
  <Columns>
    <Column>
      <li/>
    </Column>
    <Column>
      <li/>
    </Column>
    <Column>
      <li/>
    </Column>
  </Columns>
</ul>

Out of the top 100 most visited websites, not a single one used valid HTML in 2022. Misplaced wrappers may play only a small role in this, but if we can author design system components that make it easier to avoid, we should.

3. Redundant elements can break styling

Just as the extra element is sometimes legitimately needed for specific styling needs, in other situations it can break your layout. When using CSS flexbox and grid, each element in the flex or grid layout must be a direct child of the parent with display: grid or display: flex.

4. Deeply nested DOM trees are annoying to work with

Finally, working with deeply nested DOM trees just slows you down.

When making sense of a bit of HTML, I scan it for landmarks and other elements that hint at the structure of the content. This becomes harder to do if the number of meaningful elements is eclipsed by those that are meaningless. Debugging becomes harder, tracking down nodes in the inspector becomes more tedious, and the joy of the craft is diminished.

Making component markup flexible

Here's a non-complete list of techniques I use to make the underlying markup in my components more flexible. Many of these primarily serve some other need but come with the bonus of reducing redundant wrappers.

1. Always accept inline styles and classes

Component libraries often come with Box and other generic container components. These primitives are encouraged, among other use cases, when you need custom styling.

Why not just use a div? In some design systems, this comes down to the use of CSS-in-JS and/or theming libraries: going via Box or an equivalent primitive usually comes with direct access to the design system's tokens. If the source of truth for your tokens is in JavaScript, a div styled with plain old CSS just won't cut it. Neither will tacking a class or inline styles onto an existing component⁶.

Box is a great primitive to expose, but should not be seen as the sole tool for style overrides. When a component disallows style overrides or limits them to a subset of CSS properties, you end up with a tree of boxes when your styling adjustments could easily have been made on the nodes already present in the DOM.

{/* Rigid style overrides */}
<Box
  borderRadius="borderRadius20"
  borderStyle="solid"
  borderWidth="borderWidth10"
  borderColor="colorBorderPrimaryWeak"
>
  <FancyComponentWithoutABorder>
    <Heading>
      <Box fontWeight="bold">Heading</Box>
    </Heading>
  </FancyComponentWithoutABorder>
</Box>

{/* Flexible style overrides */}
<FancyComponentWithoutABorder
  borderRadius="borderRadius20"
  borderStyle="solid"
  borderWidth="borderWidth10"
  borderColor="colorBorderPrimaryWeak">
  <Heading fontWeight="bold">Heading</Heading>
</FancyComponentWithoutABorder>

So — whether you're limited in the use of vanilla CSS because of design tokens or you just want to formalise how styles are overridden, make sure you expose a way of doing so on every component. If people need to adjust component styling, they will. You may as well make targeting the right node as easy as possible.

2. Make the root node tag customisable

Overriding the root node tag of a component is usually exposed via an as prop like so: <Box as="header">.

It's uncommon for the as prop or equivalent not to be provided these days. Just to explain its importance, here's one way you end up with extra DOM nodes when you're not allowed to modify the rendered HTML element. Say you want to render a list of cards:

<Stack spacing="small">
  <ul>
    <li>
      <Card></Card>
    </li>
    <li>
      <Card></Card>
    </li>
    <li>
      <Card></Card>
    </li>
  </ul>
</Stack>

Using as, this could be rewritten as follows:

<Stack as="ul" spacing="small">
  <Card as="li" />
  <Card as="li" />
  <Card as="li" />
</Stack>

Even worse than a component that doesn't provide an as prop is one that doesn't provide an as prop and renders something other than a generic div⁷. A good example is something like Heading. It may be tempting to enforce one of h1–h6 elements under the hood. But (as much as you discourage it in your documentation) that would be making the assumption that your Heading component will never be used to show arbitrary text that just needs to look prominent.

3. Consider if your component needs to output its own root node

Similarly to as, I would like to see much more of asChild or an equivalent in the wild.

Popularised by Radix UI, asChild is a way to merge a single-node component's props onto its own single child node. The node itself will be omitted, but its props and functionality will be copied into its child. This works great in highly composable components, or when one component provides behaviour while the other provides styling, as illustrated by Radix UI's own examples:

import * as React from "react";
import * as Dialog from "@radix-ui/react-dialog";
import { MyButton } from "./my-button";

export default () => {
  return (
    <Dialog.Root>
      <Dialog.Trigger asChild>
        <MyButton>Open dialog</MyButton>
      </Dialog.Trigger>
      <Dialog.Content>...</Dialog.Content>
    </Dialog.Root>
  );
};

DialogTrigger might by default return a <button>, but we want to use our own MyButton as the trigger instead. Without asChild, we may end up with <button><button></button></button>, where the extra element is both invalid and unnecessary. With asChild, the output is a single <button/> with styling from <MyButton> and dialog trigger semantics from <Dialog.Trigger>.

Support for asChild is especially critical in libraries that provide highly composable components (of which Radix UI is a great example). Compound components come with a range of benefits, but they are also more prone to outputting bloated HTML unless you specifically build in safeguards to avoid it.

If you want to build in asChild support into your own components, Radix UI provides the nifty Slot utility to handle merging of event handlers and other props for you.

In more specialised components, it may not always be appropriate to support a full merge of props à la asChild. But the basic idea still stands: just because we use a HTML-like entity as the vessel for a component doesn't mean it needs to output an actual HTML node. Some examples:

• passHref in Link from Next.js: <Link href="/foo" passHref><Text>Link</Text></Link> outputs a single <a> tag.
• Enhancing the behaviour of child nodes: If a component is responsible purely for attaching attributes to its child node, why introduce a wrapper? A good example is the VisuallyHidden component, which usually just adds a set of inline styles to its content. If its content consists of multiple sibling nodes, the wrapper is justified. But if it wraps a single element, the set of styles can just as well be attached to that one element, and the wrapper omitted.
• Wrappers that operate on multiple children: If a wrapper node only has an effect when it has more than one child, why not double-check the number of children before applying that effect? Standard components such as Stack or Inline are great examples of this, because they're responsible for laying out multiple children along an axis. Single child → no gaps or axes to work with → why the wrapper? ⁸

4. Make your stacks smarter

This one is a bit special, as it concerns a specific component: the ubiquitous Stack (sometimes differentiated as Stack and Inline or Flex, depending on the implementation).

Let's go back to the Card example from the start of this post and extend it to support a subtitle:

<Card>
  <Stack spacing="medium">
    <Heading level={2}>Card title</Heading>
    {subtitle &&
        <Heading level={3}>{subtitle}</Heading>}

    {description &&
      <Text>{description}</Text>}
  </Stack>
</Card>

The optional subtitle happens to sit closer to the title than it does to the description, which makes the wrapper Stack with medium spacing insufficient. Along comes a second Stack, this time with small spacing:

<Card>
  <Stack spacing="medium">
    <Stack spacing="small">
      <Heading level={2}>Card title</Heading>
      {subtitle &&
          <Heading level={3}>{subtitle}</Heading>}
    </Stack>

    {description &&
      <Text>{description}</Text>}
  </Stack>
</Card>

We are well on our way into div soup territory.

Why can't stack-like components support variable spacing between children? Neither flex nor grid layouts currently support variable gaps, so at the moment the implementation for something like this would necessarily rely on margin on each child rather than gap on the wrapper.

This would violate a core tenet of design systems — that elements should never be responsible for layout outside of their own bounds.

I think this violation is justified. Unless you're working with straight-up lists of repeated elements, it's uncommon for a well-designed UI to feature more than 2–3 consequtive elements with equal spacing anyway. The result is deeply nested stacks upon stacks upon stacks when really we should be dealing with a flat list of siblings — unnecessary wrappers at their most obvious.

I encourage supporting something like <Stack spacing={["small", "small", "medium"]}> alongside the standard <Stack spacing="medium">. Because stack-like components are so ubiquitous, the impact on redundant HTML will be noticeable.

5. Raise awareness in documentation

Markup manipulation should be normalised in your documentation.

As mentioned, the as prop is quite a common feature in component libraries, but it's fair to assume it's not used as often as it could be⁹. Could insufficient documentation and awareness be one of the causes?

I'd argue that it's rare to achieve great markup hygiene at the page level without frequent use of one of the described techniques (style overrides and the as prop being the most critical). As such, their use should be illustrated in all documented code examples to make them more realistic.

Instead of illustrating the use of the Columns component with a bare-bones example like this:

<Columns>
  <Column>A column</Column>
  <Column>A column</Column>
</Columns>

…consider adding (at least somewhat) realistic semantics into your code snippets:

<Columns style={ { height: "100vh" } }>
  <Column as="nav">Navigation</Column>
  <Column as="main">Main content</Column>
</Columns>

It also helps to mention the default root HTML element that a component outputs in its description (someone consuming your docs will be forced to take the extra second to consider whether that element needs overriding).

Finally, it goes without saying that it helps to frequently look at and analyse the HTML your components produce. Storybook addons like HTML preview and Accessibility are as much (or more) about raising awareness as they are about functionality.

When viewed in the context of a single component, redundant HTML can seem inconsequential. And given the current zeitgeist around AI, obsessing about an extra div may feel a bit 🤡

But when viewed collectively and across products, the importance of lean markup is compounded. In her article, Building conscious design systems, Amy Hupe wrote:

If we can use our design systems to speed up meaningful work, standardise things to a high quality, and scale the things we actually want to reproduce — then the reverse is also true. It means that we can also use our design systems to speed up problematic work, standardise things to a poor quality, and scale things we don't want to reproduce.

Bloat scales. Let's make it easier for component consumers to avoid it.

It's why I always feel a bit lost when using CSS modules or CSS-in-JS libraries. What do you mean I can name my classes or styled components whatever I want? It's not unheard of for people to use BEM with CSS modules. This might seem silly  —  they solve the same problem, after all. But perhaps it shows that rigid class naming conventions are attractive beyond their power to avoid collisions. For better or worse, they allow us to gauge the role of each selector from the stylesheet alone.

In our preoccupation with classes, it's easy to think of them as the default selector. Historically, when people have talked about targeting elements by their attributes, it's been in the context of neat tricks or one liners. You make a mental note to use a[href^=https://specific-domain.com] the next time you want to use pink underlines for each link to one specific domain, and promptly forget about it forever. Or, to give a more practical example, attribute selectors have been recommended as a kind of linter or debugger for invalid HTML (img:not([alt]) { border: 1rem solid red; }).

More recently, the idea to treat attribute selectors on par with classes as first-class citizens has been proposed more widely. We're no longer talking about edge cases, but challenging the very defaultness of classes, all while not giving up that sense of structure that many of us look for in CSS naming conventions.

The two articles that have stood out for me are:

• Represent state with HTML attributes not class names by Aleksandr Hovhannisyan
• CSS classes considered harmful by Keith Cirkel

Aleksandr and Keith both advocate for attribute selectors instead of class names, but while Aleksandr describes the more conservative approach of preferring attribute selectors where one already exists on the HTML element, Keith goes a step further and proposes adding your own data-* attribute instead of another class when you need something to hook into.

Let's look at both more closely.

Representing native state

Aleksandr Hovhannisyan makes the case that classes are too often used to style different states or variants of an element, where that state might  — or, critically, should —  already be semantically represented by other properties such as ARIA attributes or pseudo selectors.

No-one objects that you should prefer input[disabled] over input.is-disabled, because most of the time it's unnecessary to add that class name manually when you already have an attribute selector to hook into. But we tend to forget that there are plenty of other native ways to represent state that we should be using anyway  — namely ARIA attributes. (Though we don't get them for free as we do with pseudo classes like :hover, :checked or :focus.)

Compare the following. Using modifier classes:

<a href="/page2/" class="nav-link nav-link--is-active">Page 2</a>

<style>
.nav-link.nav-link--is-active { }
</style>

Using ARIA attributes:

<a href="/page2/" class="nav-link" aria-current="page">Page 2</a>

<style>
.nav-link[aria-current="page"] { }
</style>

The crucial point here is that aria-current="page" should be included regardless of the styling needs of an active link, and I can't think of a reason why we should ever add an extra class where the state can already be selected for in a different way. Worst case scenario, this would mean you're implementing state management twice.

This promotes an a11y-first mindset — if there is no attribute or pseudo selector available to represent the state we wish to style, should we add one? Are we using the right HTML element? We are forced to go through a mental flow chart of native, semantic HTML and CSS features we could tap into before resorting to classes.

I'm reminded of Testing Library's guiding principle to only ever reach for the testId element selector when you've ruled out all other, more semantic querying options. What if we treated classes a bit like test IDs, appreciating them as a robust, generic fallback option that we can reach for when there are no other appropriate, semantic attributes available on the element?

Other people have covered thoroughly the many examples of using ARIA attributes and other semantic selectors for styling, so I won't cover any more here. Do have a read if you're interested:

• Style with stateful, semantic selectors by Ben Meyers
• User facing state by Scott O'Hara
• Using CSS to enforce accessibility by Adrian Roselli

Representing custom state

Aleksandr Hovhannisyan explains well how the use of attribute selectors can result in better UX. I find it a satisfying coincidence that Keith Cirkel reaches the same conclusions coming from a place of developer experience. He highlights the DX issue with classes:

Classes, being a list of arbitrary strings, have no key-values, no private state, no complex types (which also means IDE support is quite limited) and rely on custom DSLs like BEM just to make them slightly more usable. We keep trying to implement parameters into a Set<string> when what we want is a Map<string, T>.

There's a well-known fundamental principle in software engineering: Make impossible states impossible¹.

My impression from Keith's article is that, at its core, this is the principle that class selectors violate. An element's classes are never guaranteed to reflect their state (nothing prevents you from adding the class button--loading to a button that isn't, in fact, loading), and classes that are used to represent one of many mutually exclusive variants are never guaranteed to be mutually exclusive (nothing prevents you from adding button--primary and button--secondary to the same button).

I love how Keith frames this as a type issue. As an example, we can look at the naming of some of Tailwind's utility classes: using a colon to group related sets of classes could be taken as an attempt to signal mutual exclusivity. <div class="sm:w-80 sm:w-96"> should sound the alarm bells because the offending logic is immediately visible in the naming.

Keith reminds us that attribute selectors can be some of the most versatile in our CSS toolbelt  — data-* attributes, combined with the rich variation in CSS attribute selectors, could be used to capture strings as well as lists — and he encourages us to embrace them. Here lies the difference between his and Aleksandr's suggestions: it's not about merely using the native attributes already present on the element, it's about adding custom ones — instead of classes — when they're not.

An example from Keith's article:

.Card { /* ... */ }
.Card[data-size=big] { width: 100%; }
.Card[data-size=medium] { width: 50%; }
.Card[data-size=small] { width: 25%; }

.Card[data-align=left] { text-align: left; }
.Card[data-align=right] { text-align: right; }
.Card[data-align=center] { text-align: center; }
.Card[data-border-collapse~="top"] { border-top: 0 }
.Card[data-border-collapse~="right"] { border-right: 0 }
.Card[data-border-collapse~="bottom"] { border-bottom: 0 }
.Card[data-border-collapse~="left"] { border-left: 0 }

It's much easier to avoid impossible states when you have different “slots” to fill in with the different groups of variants for your element, rather than shoving all of them in a single cobbled up string in class, however disciplined your naming may be.

And there's a reason why <article class="card" data-align="left" data-size="small" /> looks attractive — it's mirroring the APIs we're used to seeing in design systems and component libraries, but bringing it to vanilla HTML and CSS. Indeed, it's a small step from data attribute selectors to custom pseudo selectors or prop-based selectors when using Web Components (think <my-card align="left" size="small" />).

Still, for now, if you're not yet using custom elements, there's a big difference between

<article
  class="card"
  data-loading="true"
  data-variant="primary"
  data-size="large"
  data-border="top right"
  data-elevation="high" />

and

<button
  aria-label="Toggle menu"
  aria-controls="navbar-menu"
  aria-expanded="true"
  disabled />

While I wholeheartedly agree with using attributes over classes when they're already present, adding your own may be a harder pill to swallow. Tapping into native attribute selectors doesn't conflict with any existing CSS methodology you may be using, but adding custom ones may require a bigger commitment and change in the overall naming conventions in your codebase. It may also make it more difficult to gauge from the HTML alone which attributes are for behaviour versus just styling concerns. And, ultimately, there's that nagging feeling that you're going against the grain by repurposing data attributes for styling — after all, selecting elements is what classes are for, and what browsers optimise for in selector performance.

Even so, it's an enticing proposal and I'm excited to see how people continue to shape it. Devon Govett endorses a split where he uses a class for the component itself, but signals all internal variants and state with data-* or aria-* attributes. There are some great insights in this thread for those who would like to dig deeper.

New favorite styling method: class names for components, data/aria attributes for states.

Attributes are so much better than classes for states. No need to mess with string concatenation of conditional class names, you can have values instead of only booleans, etc. 👍 pic.twitter.com/eNs9xYjiPO

— Devon Govett (@devongovett) October 2, 2022

While I'm mostly working on codebases using CSS-in-JS these days, where little of this is of much relevance, I can't wait to rewire my brain to reach for attributes more often. Styling based on ARIA attributes encourages more accessible markup, and styling based on custom data attributes makes it more robust and readable — a better experience for users and developers alike.

Does including a Konami-code triggered Easter Egg negatively impact keyboard accessibility?

(Konami code, a sequence of specific keypresses, is a cheat code originating from video games. It's sometimes used as a way to trigger easter eggs on websites.)

Much of discussion focuses on how likely it is that the key sequence could be triggered accidentally. The implication is that by minimising any chances of encountering a feature, you can avoid putting in the work to make it accessible. This may be true for Konami code, but it made me wonder — instead of keeping easter eggs and bonus content neatly tucked away so that they don't break when assistive technology is involved, how often are these elements added with inclusivity in mind from the start?

We've been taught that UX is not only about function, but about delight, whimsy, wit, and beauty. But when it comes to accessibility, we tend to take the term literally: can this be accessed? Articles on accessibility focus on functionality, and the small, non-essential moments of delight are reserved mostly for mouse or touchpad users with good eyesight. What's the equivalent of a playful design for people who don't necessarily experience the visual, high-speed or animated version of it?

Any visual, hearing, motor, vestibular or other impairments I face are mostly situational, so I can't draw on experience here. I can spot creative touches that don't work well for users of assistive technologies (I'll share a few below). It's a little harder to find those that are added specifically with that audience in mind: by definition, they would likely be lost on me. But when I asked local leading accessibility consultant Jakob Rosin for his input, his examples, too, were mostly about functional alternatives, not the playful ones.

I'll cover both here. Training myself to notice these alternative features, while not strictly fun in the sense that I was going for, still helps me move away from thinking of one type of design as the default. Different representations should not be a mere means of accessing some one true default — they're opportunities to add features and creative touches that shine only in a particular medium.

Playful design as a progressive enhancement

Let's start by looking at how common playful touches can leave out users of assistive technologies.

The simplest example is anything triggered by a pointing device. Think interactive gradient backgrounds that change colour as you hover across a page, particle animations that respond to pointer speed and direction, or any non-essential hover state that doesn't also respond to a focus event. When not tied to critical functionality, these features are clearly a progressive enhancement, sometimes even intentionally a bit hidden. And you should not feel guilty for getting creative with pointer interactions! But consider the equivalent for a screen reader user — is there anything in your design that elicits the same “huh, that's neat” reaction from someone who can‘t see it?

To give an example, check out the interactive particle animation presented front and center on this agency landing page:

I do love the slow, satisfying inertia that ON has fine-tuned to perfection. It invites play. There's a competitive advantage to features like these, especially in agency land (it's a bit of a flex, isn't it). But in many cases the interaction cannot be triggered by keyboard, and there are no alternative, accessible labels — never mind that many people prefer not to encounter motion at all when browsing the web. s.e. smith writes in My war on animation:

I'm not the only one who struggles with parallax scrolling […]. It can also be tough for screen readers to work with, particularly when it's being used for something like a graphics-heavy display of data. Other people just find it annoying, which seems fair. Could there be an alternative plain or clean version of the same data, presented with the same care? […] Rather than viewing access as an imposition that narrows your options, think of it as an invitation to think outside the box.

If a touch of whimsy suits only one particular medium, could we find ways to compensate in others?

Another example is Google's long-standing design for their pagination where an o from the stretched out Gooooooogle accompanies each number in the list of results, as if to vocalise how loooooong it is. It's cute, in an Old Web kind of way. (If anyone knows where I could learn more about the history behind this bit of design, please share!) When you look at the implementation though, the play on… erm, word, is lost inside a neat list of links: Page 1, Page 2, Page 3… Functional, but boring compared to the visual.

Let's look at error pages, a quintessential outlet for playfulness in design. When you interrupt your users with an error, you probably want to do so with friendly humility. Any chuckle you can elicit with a creative illustration will soften the message more. It's curious, then, to see suggestions like the following in a guide on UX copywriting:

This is a 500 error page, so instead of the image saying something like: “Drawing of a woman screwing in a lightbulb”, it makes more sense to use “500 internal server error” as the alt text.¹

I'm not going to argue against this specific use case, as alt text is notoriously difficult to get right and heavily dependent on context. And when it comes to clever illustrations, it may just not pack the same punch. If the copywriting does much of the heavy lifting to deliver the quip, you can probably consider the illustration a bonus. But I would love to learn of examples where the overall message is just as playful for people seeing it, hearing it, viewing it zoomed in or zoomed out, and with or without images or motion.

I'd like to look at one more type of non-essential information presented visually, and that's look and feel. Serif or sans serif fonts, rounded or pointy corners, bright or pastel colours… there's a lot of tacit information that these small design choices collectively convey. But it is precisely the small design choices that I often see ignored — classed as “decorative” — when reading about accessibility. This leaves the entire burden of branding on voice & tone alone.

In The surprising truth about pixels and accessibility (an excellent overview of the long-standing debate), Josh Comeau writes:

Similarly, how about border widths? It doesn't really make sense for a border to become thicker as the user scales up their preferred text size, does it?

This is subtle, but worth challenging — why not?

Yes, we run into thorny issues around whether the browser zoom function should apply to the full page or just text². Your unit strategy also makes little difference for users who only zoom marginally for reading comfort. For someone who routinely browses the web at 250% zoom level though, odds are they cannot make out 1px borders at all. Why shouldn't we take any opportunity to keep the nonverbal cues in our designs intact for everyone?

Consider these different uses of borders on bbc.com. Some scale with the text, some don't.

The differences are so subtle, but they provide a window into how designers reason about accessibility when it comes to non-essential content.

It's fair to say there is a disproportionate focus on visuals, illustrations and motion when it comes to creativity and playfulness. Without the lived experience, it's tricky for me to imagine equivalents in other representations. But I'd like to share a couple of examples where it has been done beautifully. Please share if you've come across others!

Playing with broken images

In How to get the most out of alt text in your marketing emails, Chris Donald talks about fun ways of leveraging alt text for people who have images disabled, or whose network connection is too slow for them to load (certainly a valid audience to consider when it comes to inclusivity).

First, it's perhaps not widely known that alt text inherits styling just like other elements. You simply don't see it unless your images fail to load and the alt text is displayed as a fallback. You can target it directly by associating the styles with the <img> element:

<img class="alt-text-fallback">

<style>
  .alt-text-fallback {
    color: var(--color-text-accent);
    font-size: var(--font-size-xxl);
    font-family: var(--font-family-display);
  }
</style>

This could be neat for text-based images such as logos: the fallback alt text could be styled as a close enough replica of the logo, and the actual image becomes almost a progressive enhancement (remember though that the alt text should remain first and foremost a signal for screen reader users, so if your logo is a link to your homepage with the alt text “Home”, you should probably keep it that way).

Taking this idea further — and this is where we get to the easter egg ! — Chris Donald describes how Sony PlayStation sliced their hero image into separate blocks with different background colours to create fallback pixel art out of those blocks if the images fail to load:

This example really captures the essence of deliberately adding alternative versions of playful touches where the standard use case (assuming images will load) doesn't apply.

And while those efforts might not be seen (nor appreciated) by the overwhelming majority of your customers, the ones who do pick up on what you've done just might appreciate it even more.

[creatures biting wetly]

I can't help but draw a parallel with closed captioning here. People with hearing loss are by far not the only ones who benefit from closed captions. Just as people on a slow connection who usually want to see images would appreciate surprise pixel art, hearing people who can't rely on audio just then will welcome well-written captions. (As a parent of young kids, I can't remember the last time I dared turning the volume up during movie night after the kids' bedtime).

“tentacles wetly squelching”

Meet the wordsmiths who gave us those brilliant subtitles in Stranger Things 4 https://t.co/aFMC4c3tSe pic.twitter.com/qrCNrt4EI0

— Netflix (@netflix) July 11, 2022

Alternative function

I mentioned earlier the distinction between alternative fun and alternative function. I've been trying my best to find IRL examples of the former, but most of what I covered here requires some imagination to fill in the gaps.

Going back to some of the examples Jakob Rosin mentioned, he focused on products that provide different functionality specifically suited to each medium. While not quite the easter egg, almost non-essential type features I was looking for, his examples highlight an interesting area of inclusive design: instead of making a feature merely accessible via different mediums, consider whether it's actually useful at all in those mediums, and provide alternatives or configuration options where appropriate.

Jakob mentions the various customisation options introduced for the lock screen on iOS 16: fonts, colour, photos, layout, and other visuals. This is fun for sighted people, possibly essential for the partially sighted, but doesn't make much sense for people who can't see the screen at all. What are the equivalent configuration options for other senses? The specific sounds your phone makes or haptic feedback it gives when locking and unlocking, for example, are not currently configurable (bar the ability to switch them off).

An example Jakob gave of a product that gets it right is Slack. In its onboarding flow, Slack asks screen reader users which order they would like to hear content presented in. For example, should the time of a message be announced before its body or vice versa? This would never make sense for people perceiving the UI visually, and that's what makes it stand out — it's a different feature, added with a different user group in mind.

We can flip this idea around. Indeed, many of the problems we face when designing for a sighted audience are not problems at all for screen reader users. For example, instead of requiring an extra action to reveal truncated labels (in tables, say), just present them in full. Screen space is not an issue here, and reading the full label is no doubt faster for the sped up synthetic voice of a screen reader than explicitly revealing a hidden portion. If you're controlling truncation in CSS with text-overflow: ellipsis, screen reader users already hear the full content as given in the source. I love this example because it makes the tooltip the alternative experience — not the ARIA label or alt text or focus state.

It might be premature to talk about playful touches when the accessibility lobby is still trying their best to get the basics down. If you're familiar with the idea of the adjacent possible, the thought that we have not only the luxury, but even the possibility to focus on fun in non-visual mediums may be ridiculous. You can't get creative with what isn't there!

Content and function obviously take priority. Still, I hope these examples sparked an idea or two. As we learn to stop viewing the visual, high-definition, high-speed experience as the default, we'll become better at noticing gaps in functionality. The fun should soon follow!

Update: 21st September, 2022

This article has been making the rounds for a while so I thought I'd share some more interesting examples of creative touches in accessible design that people have brought up as feedback. It's been encouraging to see that the landscape isn't as devoid of playfulness as I initially thought!

• @franktalisman shared a presentation by Vasilis van Gemert on voicing animations by making screen readers sound a bit unexpected and silly.

  See: Exclusive Design

• @JoshWComeau shared his generative art tool, Tinkersynth, which gives keyboard users more control over sliders than mouse users.

  See: Tinkersynth

• As a less encouraging example, @ckundo brought up stramps — ramps that blend into staircases. You can see how the intention might have been to bring an artistic touch to something perhaps a little boring, but the result is a dangerous loss in functionality.

  See: The problems with ramps blended into stairs

• Jakob Rosin mentioned a clever way of bringing more expressiveness to team or about pages on marketing sites by adding audio clips of people's voices next to their photos.

  See: Voxmate

• Jakob Rosin also brought up audio logos — adding an alternative audio representation to a visual logo. Sonic branding is a concept traditionally more common in advertising and broadcasting, but, indeed, there is no reason why we couldn't use elements of it in digital products and services, too.

• [2nd October, 2022] I was listening to Episode 049: Accessibility of The CSS Podcast, where Adam Argyle describes how he animates outline-offset on focus states from a larger focus ring to a smaller one, creating a cool zoom effect when using the keyboard to tab through elements.

It was good timing. While I'm a front-end developer at heart, I've rarely had the luxury of focusing on it full time. I've been dipping in and out of JavaScript, never fully caught up, always trying to navigate the ecosystem all over again each time a project came up. And framework fatigue is real!

So, instead of finally getting into Rollup to replace an ancient Browserify build on an old codebase (which could also really use that upgrade from Polymer to LitElement…), I decided to go “stackless”. I took a long-time idea for a motion design project and built it using nothing but features native to the browser: vanilla JS, ES6 modules and web components.

Working on a codebase with no dependencies has been a way of rediscovering exactly what I get for free in 2021, and what value I'm adding by bringing frameworks, transpilers and bundlers to the mix. I'd like to share what I learned (and what I needed to unlearn) in the process.

The project

The project itself, Schematics: A Love Story, is a collection of animated diagrams from a visual poetry book by the same name. The animations dotted throughout this write-up are examples from the project: SVG created programmatically with modular, vanilla JavaScript, encapsulated in a web component, sitting inside a framework-free codebase.

The Stackless Way

Daniel Kehoe is not alone in his push-back on the complexity of the modern web. Frank Chimero's Everything Easy is Hard Again gets to me every time, and, more recently, I enjoyed this lighthearted rant about the lack of appreciation for vanilla JS.

Appeals for external JS dependencies to be added with thoughtful intent have become common, but some schools of thought question the concept of single-page apps as a whole: server-side rendering is still a thing, after all. Pages can also be pre-built into a fully static site and served from a CDN (see Jamstack). These approaches recognise that we can move some of the complexity currently managed by front-end frameworks elsewhere on the stack.

But Kehoe's series of articles on going stackless feels a little different. It's not just about JavaScript — it's a wholehearted devotion to the native features of the web as a platform (Routing? Just make sure every URL matches a .html file!)

There are limits to this kind of purism, of course. The Stackless Way, to me, is less of a realistic approach to building production web apps and more of a learning and introspection tool, a way to take a step back and fall in love with the platform again.

Being all about motion design, my own project relied on many a setTimeout and page transitions — a single-page app, really… just handcrafted. The two main technologies that made it possible are ES6 modules and web components, which, along with module CDNs, form the pillars of The Stackless Way.

ES6 modules

If you've been developing for the web for some time, you might remember doing this:

<head>
  <script src="/js/vendor/jquery.min.js"></script>
  <script src="/js/main.js"></script>
  <script src="/js/subscribe.js"></script>
  <script src="/js/gallery.js"></script>
  <!-- Many more script tags whose specific ordering was a source of bugs and frustration -->
</head>

Listing all required scripts separately in the document <head> was all we could do given the lack of support for a native import/export mechanism in JavaScript. This was, of course, suboptimal:

• each script tag initiates a HTTP request;
• there is no namespacing (all scripts exist in the global scope);
• the order of execution is linear, and maps directly onto the ordering of the script tags.

To combat this, approaches to modularity in JavaScript have proliferated over the years (AMD, UMD, CommonJS), and along with them, build tools and bundlers to convert the modular code into something that the browser understands.

ECMAScript Modules (also referred to as ESM or ES6 Modules) is the first native standard for modules in JavaScript. I emphasise native here because that means we can ditch the build tools and bundlers in favour of <script type="module"> in HTML and import/export in JS:

<head>
  <!-- Single entry point for a dependency graph of any depth -->
  <script type="module" src="main.js"></script>
</head>

// main.js
import Gallery from "./Gallery.js";
import SubscriptionForm from "./SubscriptionForm.js";

// Gallery.js
import Swipe from "./helpers/gestures.js";

export default class Gallery {}

Native support for modularity is the most important step towards a build-free codebase. If I had access to only one ES6 feature for the rest of my life, I'm confident that modules would take me most of the way there when it comes to well-structured native JavaScript.

And not having to build your JS app is magical. Setting up the directory structure for Schematics, I was giddy with excitement skipping npm run build and seeing my source files mirrored — as is! — in the browser. It reminded me of when I first began building websites and double-clicking index.html was enough to see your work in the browser.

You do need a local server if you're using ES6 modules (so double-clicking an HTML file might be a thing of the past for good). But there's no lag between editing your code and seeing changes in the browser, and the source code you see in the inspector is exactly what you typed into your editor (no sourcemaps!).

Nevermind the faster edit-compile-debug cycle — this speaks directly to Chimero's concern about the lack of legibility in today's codebases as an obstacle to learning the craft:

Before, the websites could explain themselves; now, someone needs to walk you through it. Illegibility comes from complexity without clarity. I believe that the legibility of the source is one of the most important properties of the web. […] the best way to help someone write markup is to make sure they can read markup.

I recommend reading Kehoe's Javascript import explained or Ayodeji's Introduction to ES6 modules for a historic overview of approaches to modularity, how we got to ESM, and how to write your own modules.

The future of app bundles

Just because you don't strictly need a build tool to run your code, doesn't mean you shouldn't use one for production builds to optimise performance. I'm referring here not to transpilation, but to minification, mangling, tree-shaking, etc.

I've been bundling JavaScript into a single app.js file for such a long time that my first instinct was to concatenate everything into a single script on Schematics, too. This, of course, will not work with ES6 modules — the concept of files is what creates boundaries between different modules, and there is no way to specify more than one module per file.

Luckily, you don't need to bundle your ES6 modules into a single file to improve performance. Let me repeat: you don't need to bundle your ES6 modules into a single file to improve performance.

Here's why:

1. <script type="module"> requests are deferred by default: they won't block document parsing.
2. Serving all modules from separate source files is great for caching, as the modules unaffected by some change can continue being retrieved from the cache. When you serve a single bundle, any one change will invalidate the whole bundle.
3. You can lazy load parts of your code by making use of dynamic imports — importing modules during runtime at the point where you actually need them.
4. You can preload critical modules with modulepreload. This starts parsing and compiling the linked modules immediately, off the main thread.
5. Finally, HTTP2 may in the future allow us to resolve the entire dependency graph from the first <script type="module"> request, and send all required files back in a single response. For the time being, this requires bespoke logic written on the server side.

And don't forget about bundle size:

If you inspect the output code generated by most popular bundlers, you'll find a lot of boilerplate whose only purpose is to dynamically load other code and manage dependencies, but none of that would be needed if we just used modules with import and export statements!

I still have some work to do to go against my first instinct to bundle. It's not uncommon for a SPA to have hundreds of JavaScript files, and the prospect of serving them all separately seems counterintuitive. Even having read up on all the reasons why I don't need to bundle my modules, I occasionally hesitated before separating some logic into its own file to avoid the extra request.

For more details and interesting discussion around ES6 module load performance and app bundles, see this thread on the ECMAScript Discussion Archives. The spec is not set in stone yet, and there are plenty of ideas floating around, some more daring than others (my personal favourite is the proposal to serve the entire module dependency graph as a .zip file).

There's plenty of ongoing module work happening in Chrome, though, so we're getting closer to giving bundlers their well-earned rest!

I also recommend reading Using Native JavaScript Modules in Production Today by Philip Walton. It explains how to serve optimised module files alongside a standard fallback single-file bundle for older browsers.

Finally, if you're looking for an alternative to webpack that supports native modules, check out Vite or Rollup.

Web components

Web Components is an umbrella term for several native technologies (Custom Elements, Shadow DOM and HTML templates) that let us bundle the markup and dynamic behaviour of an element into a reusable piece of code, on a high level no different to the React or Vue component. As of May 2021, All the Ways to Make a Web Component lists 55 variants of a hypothetical <my-counter> component for comparison across bundle size, coding style and performance. Native web components, of course, stand out because they have no external dependencies (and, consequently, an unmatched tiny bundle size).

Congrats, you're now ready to go 🎉

— Web Component Bytes (@wcbytes) August 19, 2021

Here are some of my own impressions of web components as compared to external frameworks when it comes to DX and architecture.

Shadow DOM and <template>

The shadow DOM, a way of keeping the internals of a component inaccessible to the main document, is a neat feature in theory, but a natural use case for it didn't really arise when working on Schematics. I've played around with the shadow DOM in the past as part of a Polymer (now LitElement) project, and I mostly remember it creating more problems than it solved, especially when it came to styling. I can see the shadow DOM being useful in cases where a component is reused across many sites and in unpredictable contexts (such as elements in a UI library); for your standard <site-specific-header-dropdown>, it doesn't add much value.

The <template> and <slot> elements (the latter only useful if you're using the shadow DOM) are presented as a means of adding hidden markup inside JS, but they feel clunky if you're used to something like JSX. Additionally, the <template> tag seems counter-inuitive if the aim is to create portable components that can be included in an app with a single import. When declared in the HTML, any JavaScript making use of the <template> makes assumptions about what's available to it in the main document. Indeed, at times the index.html in Schematics felt like a dumping ground for various <template>s, rather than a neat overview of the page structure.

HTML Imports was a proposal that might have allowed us to package JS and HTML together into a single bundle, making <template> the star of the show. Unfortunately, the feature never took off.

Another proposed feature is a means to add variables, simple statements and event handlers to nodes in a <template> tag. The gist of it is similar to what you'd currently see in front-end frameworks:

<template id="card">
  <card>
    <h2>{{title}}</h2>
    <div>{{description}}</div>
    <a href="/card/{{id}}">Read more</a>
    <button handler="onEdit">Edit</button>
  </card>
</temlate>

Being accustomed to built-in data-binding in frameworks, until the variables above are automatically updated, the feature feels half-baked. As it stands, it's difficult to gauge the full, declarative markup of a component in one place, as update logic is scattered throughout the class with query selectors, innerHTML, document fragments and the like.

If you'd like variable and event handler support in <template> now, GitHub, who use vanilla web components internally, provide a polyfill for the minimum viable bits of the proposal. As for data binding, Danny Moerkerke describes one approach to implementing it yourself: Data binding for Web Components in just a few lines of code.

Extending native elements

The web components feature I was most excited about, and one that a third-party framework inherently cannot provide, is the ability to extend native HTML elements. This allows you to inherit any built-in behaviour for that element in your component, including accessibility-specific properties. Unfortunatley, Apple have decided not to support customizable elements in Safari.

This is disappointing. Using front-end frameworks, we often implement our own, more snazzy versions of native HTML elements. Input elements especially, such as dropdowns and radio buttons, are tricky to style using CSS and often end up reproduced with JS. But reproducing the required ARIA attributes, keyboard navigation and the like requires extra effort — something we would get for free with customizable elements.

Components all the way down?

While ES modules sparked excitement for the future, I was left underwhelmed by the prospect of native web components replacing traditional front-end frameworks. In hindsight, weighing up web components against JS frameworks was missing the point of the exercise. It's not about making more of your JavaScript vanilla; it's spotting opportunities to forego JavaScript in the first place.

Being a React user, attaching my App.js root component to a <div id="app"> root node and working down the tree, in smaller components, is how I'm used to thinking about SPAs. Though you can attach your component onto individual DOM nodes (and you could easily mix and match frameworks, too), the more standard approach is to let the framework drive the whole page.

This will quickly fall apart when using web components. At the level of the atomic UI element, they shine; for the business logic and user flows, you should defer to a different part of your stack. As for static content — why render it with JavaScript if raw markup does the job perfectly?

And so, I caught my mindset shifting from an app that's just one big component to not using components by default, breaking the link between component and framework in the process.

In the case of Schematics, I ended up with just a couple of main custom elements sitting neatly in the middle of native HTML tags. A simplified illustration of the idea:

<body>
  <header></header>
  <aside></aside>
  <main>
    <schematics-figure></schematics-figure>
    <schematics-figure-toolbar></schematics-figure-toolbar>
  </main>
  <footer></footer>
</body>

It seems obvious in hindsight that a component on a website should encapsulate the behaviour and appearance of some bit of UI. But, as this article nicely puts it, with the proliferation of JS frameworks, “we've landed over in the ditch on the other side of the road: putting all sorts of behaviour into the same JSX-denoted structure as Components”.

“React renders your UI and responds to events” was how it was introduced. Not: “React is a way to transform and execute all your logic in a hierarchy of declarative markup”, as it has devolved into in many cases.

The above thoughts are mostly based on first impressions. If you're interested in a more detailed review of the state of the web components spec, I recommend this excellent article by Andrea Giammarchi which takes a more critical look of the feature in the context of the 30-year history of the web.

The future of stackless

Schematics was a simple project as far as architecture goes, and web components and ES6 modules took me most of the way there. I can't see myself building a complex app without a framework. Fully static sites, too, are simpler to build using a generator like Jekyll: something like markup reuse across pages is impossible when you only have the browser and text editor to work with (the humble <iframe> might disagree with me here…).

Technical limitations aside, an issue I became aware of during this exercise was a lack of standards in vanilla JavaScript. Because we're so used to the framework dictating how to structure our codebase, there aren't many established guidelines should you decide to handcraft your JavaScript. Never mind the high-level architecture — even the way you define a class, use static variables, or implement composition all have a range of approaches to them. Web components fill in the gap when it comes to the UI; perhaps if more developers dared to go framework-free (when appropriate!) discussions around best practices would be more productive.

Know the platform

Developing web apps without frameworks or build tools is not an end goal in and of itself. As Daniel Kehoe put it in the stackless newsletter:

I don't think we'll be talking about “stackless” in a few years. It's just going to be part of any web developer's professional bag of tricks.

I'd love to see that happen. I have a special disdain for beginner JavaScript tutorials that have you run create-react-app as the first step, and this exercise has only strengthened my conviction that every beginner programmer should get to grips with HTML, CSS and vanilla JS before delving into frameworks. Features native to the web are what all frameworks share, and knowing the platform makes for a stronger foundation in the face of change.

Postscriptum: Stackless stylesheets?

I'm so used to writing LESS or SCSS, or, more recently, setting up a set of PostCSS plugins, that not having a preprocessor didn't cross my mind at first.

Indeed, Kehoe encourages the use of CSS frameworks and/or preprocessors “until libraries of custom UI elements are more broadly available”.

But such a big part of the appeal of stackless for me was running all source code in the browser as is — having a preprocessing step for CSS would ruin that. So, in the spirit of the exercise I limited myself to vanilla CSS.

I persisted with this right up until the first media query came along, and things began to look nasty. Yes, modern CSS does get you 90% there; custom properties are a real workhorse (don't forget, no preprocessor can give you properties that update during runtime, or that you can set/get via JavaScript). But the lack of native support for nested selectors (along with the parent selector) I cannot live without, and that extra 10% makes a world's difference.

Stackless CSS isn't there yet. Use a preprocessor.

Update: 21st May, 2025

I've been pleased to see a lot of resources pop up that take a vanilla-first approach to teaching and discussing building for the web:

• HTML for people teaches anybody, with or without any prior experience coding, to make and publish a website using HTML.
• A manifesto for small, static websites
• Plain Vanilla — An explainer for doing web development using only vanilla techniques. No tools, no frameworks — just HTML, CSS, and JavaScript.

Articles on fluid type often introduce the topic by explaining how it can remove complexity in styling¹. One example:

I wanted to reduce the number of media-queries, but maintain responsiveness. I wanted to reduce the CSS footprint of the website. But above all, I wanted to make my CSS more maintainable. Adding fluidity for font-sizes, element sizes, and spacing contributed to achieving this goal.

A better developer experience is valuable in its own right. But—compared to a well-executed breakpoint-based design—what exactly is the UX impact of fully fluid type?

Nothing much, is the short answer. A thoughtfully implemented fluid type system won't affect users in any meaningful way—positive or negative. Maybe that's why discussions on fluid type often just gloss over readability. Plain and simple, it really is mostly about the technical optimisations it affords.

Still, even if subtle, I can't help but wonder about how fluidity in design impacts people, and how it matches our expectations of using the web. So, here are my thoughts and findings—some concrete, stemming from visual design and typographic theory, and some of my own (wild?) speculation.

Fluid sizing vs breakpoint-based sizing

Let's start by getting size—and why it's not what matters here—out of the way.

First, the obvious: fluid typography is less about the outcome, and more about doing the same thing in a slightly different way. Imagine a breakpoint-based website that shows 14px text on mobile and 22px text on desktop. After you ditch the media queries and scale the text fluidly from 14px to 22px, a lot of people will still go on seeing roughly 14px text on mobile and 22px text on desktop.

It's the in-between screen sizes where fluidity makes more of a difference. But here, I think everyone can agree that text set at 17.6px on a 540px screen and scaled down to 15.2px on a 414px screen is not fundamentally better than showing 16px text on both. We must remember that screen width is only a convenient proxy to a much richer and unpredictable viewing context, which, at this level of tiny adjustments, will likely undo any efforts to make sizing perfect.

Can we count on context? Can we assume that everyone holds a phone or tablet at the same distance, or that desktop browsers are all hunched over a desk? […] Until computers sense a user's reading distance and adjust page scale proportionally (sounds like a nightmare, right?) we'll have to make these sensible generalizations.

Looking at where fluid font sizing can go wrong, the danger is tying it too intimately to the viewport, resulting in text that becomes too small or too big too fast. In 2021, though, this is mostly a non-issue. With the help of new CSS features, smart implementations avoid extreme scaling by only “sprinkling” the calculation with a tiny viewport multiple, and clamping it to a reasonable minimum and maximum—all the while keeping everything accessible!

body {
  font-size: clamp(1rem, 0.5rem + 2vw, 1.625rem);
}

So—fluid typography, if carefully implemented, won't harm readability. But it also doesn't have much of an edge over a handful of well-chosen breakpoints and font sizes.

Display text and line length

I tried and failed to find many specific areas where viewport-relative typography does outperform breakpoint-based sizing in terms of readability. Here are two: setting display text and maintaining consistent measure.

• Display text

  Large textual elements such as titles or bold visual statements look more striking when they are tied to the viewport size. Richart Rutter puts it nicely when he says that “display text, as defined by its purpose and relative size, is text to be seen first, and read second”.

  In other words a picture of text. When it comes to pictures, you are likely to scale all scene-setting imagery – cover photos, hero images, and so on – relative to the viewport. Take the same approach with display text: lock the size and shape of the text to the screen or browser window.

• Consistent measure (line length)

  It's widely known that there exists an optimal line length (measured in words or characters) for comfortable reading. Line length can be unpredictable at different screen widths for text whose size is static.

Viewport-relative sizing easily addresses both of these concerns². It's worth pointing out, though, that while it's probably the obvious solution for setting display text (unless you're happy with JavaScript), it's by far not the only alternative for achieving consistent line length. In addition to good old media queries to control text container sizing³, you can also use the ch unit to specify a max-length for a block of text. Ultimately, don't forget that on screens, there is a relatively wide range on line length where reading comfort isn't compromised, and it's not necessarily tied to text size.

When designing a responsive website, start with a comfortable font size and an ideal measure to help determine break points. But when the time comes (as it always does), let the ideal measure go.

A note on accessibility

Allowing people to retain control over the font size displayed in their browser is one of the most basic of accessibility requirements. Matej Latin thoroughly compared the pros and cons of different fluid type approaches in The State of Fluid Web Typography, and many of them feature issues of accessibility. As mentioned above, it is possible to make fluid typography accessible by combining viewport units with rem or em (preferably rem)—this ensures text zooming is functional and that the browser's default font size is respected.

Still, Latin's line of thinking resonates with me:

We shouldn't be focusing on making our font sizes scale nicely for every screen width. We should make our texts easy and enjoyable to read to each and every one of our users. This means leaving some of the control over web typography in their hands. At this moment, fluid web typography interferes too much with that.

This rings true even for fluid type that ticks the accessibility boxes. It's especially relevant when laptop/desktop users resize their browser—more on that later.

I'd be very interested to hear of more readability-related cases for or against fluid text sizing. As it stands, I'm not convinced there is a strong argument.

Next, let me shift focus from the text itself to the interface as a whole. Can the extent to which fluidity is applied create unexpected usability issues?

Fluid type or fluid interface?

Similarly to readability, how much of the content on your site should scale fluidly is something I rarely find discussed. Perhaps you consider fluidity important only for display text, as suggested above; maybe it's all the body copy so that you can maintain consistent line lengths. There's the option of making type fluid only on handheld devices, where there's less room for drastic layout changes across sizes⁴.

I'm keen to hear if there are best practices here that I've missed, but it seems to me that applying fluidity anywhere can easily trickle down to the entire interface (especially if the aim is to have fewer breakpoints). Having scaled the font size, you need to scale line heights and spacing around elements. But most interface elements contain some text; you go around adding a vw here, a vmin there, and suddenly the majority of your interface is fluid.

At the extreme, this can result in a design that scales fully proportionally and maintains its aspect ratios everywhere. It's as if you're looking at a picture of a website, not a live interface.

Common sense says that most uses of fluidity will fall somewhere in the middle of that spectrum. Still, it's interesting to speculate on how full fluidity might end up harming usability.

Resizing windows

Everyone resizes their windows. Your site's visitors are probably not doing it to scrutinise your responsive design, but there may be other, very practical reasons at play.

I make a window bigger when I want to see more information, not the same information presented in a larger size. A reason for making windows smaller might be wanting to fit multiple windows next to each other and work with all of them simultaneously (think task-based workflows such as editing in one window and viewing references in another). I have no data to back this up, but my intuition says that it's the amount of available space, not the size of visible content, that people are playing with when they resize windows.

When I imagine a fully fluid interface, I'm reminded of how Frank Chimero describes edgelessness as a core characteristic of designing for the web. A fully fluid interface will stubbornly stick to its edges, choosing to scale its content instead of adjusting its layout. To me, this feels annoying in the same way that scrolljacking feels annoying. To use Chimero's terms, it goes against the grain.

Taking a step back—as mentioned before, using viewport-relative units for just your text and scaling the whole design proportionally are very different things. But in all cases it's worth considering for a moment how and whether people expect content to scale during resizing. Browsing a blog? It probably doesn't matter. Referencing a dense data table while working in a separate window? Maybe don't go crazy with fluidity.

One (fluid) size fits all

I'm verging on the hypothetical now, but for the sake of argument, here's a final thought on how excessive fluidity in interfaces can negatively impact UX: the loss of pressure on developers to adapt the design.

If things scale proportionally and line breaks stay where they ought to, everything technically looks great on a wide array of screen sizes. At the extreme, you might get away with separate mobile and desktop layouts, with everything in between relying on fluidity.

But this goes back to the previous point about people wanting to see more content, not the same content bigger. The extra space afforded by larger screens should be seen as an opportunity to adjust the layout so the viewer can take full advantage of their screen real estate. Conversely, on small screens, with a fluid interface you can juuuuust push at the boundary of what's acceptable, because everything fits, after all.

How large should images be? When does the site look awkward & disjointed? When do things get too large? Is it appropriate to slide this layout's columns out into additional sidebars […]?

It's not that anyone would purposefully neglect responsive design. But it does become easier for things to count as passable. At the very least, subtly adjusting designs for many screen sizes (“tweak till you're cross-eyed”, in Walton's words³) is an outlet for creativity and craftsmanship, and it would be a shame to start seeing less of that.

To recap: I explained why fluid font sizing isn't inherently better or worse for UX, aside from a couple of minor, specific areas. I also speculated on how excessive fluidity can become problematic. Many of the issues raised are subtle, but I wanted to raise them nonetheless and add to what otherwise feels like a developer-centric discussion.

Personally, I'm happy to stay with responsive approaches for now. I do want to make a point of endorsing fluid type and its simplicity: it's a clever technique that when thoughtfully implemented can create beautiful typography that scales exactly where you want it to, challenging the view that dimensions on the web should be fixed. But as it stands, I'm not convinced the value added is worthwhile.