DEV Community: Timothy Foster

Professional Programmer Proves Prolog Prolongs Productivity

Timothy Foster — Tue, 01 Apr 2025 11:03:23 +0000

At least... probably 🙃

productive(X) :- not(takes_breaks(X)).
takes_breaks(X) :- not(debugging(X)).
debugging(X) :- uses_prolog(X).

programmer(aurora).
programmer(eventide).

uses_prolog(aurora).
uses_javascript(eventide).

Prolog is a logical language. Therefore, its output is truth:

?- productive(aurora).
true.

?- productive(eventide).
false.

Hence, the conclusion: Prolog prolongs productivity, Q.E.D.

Note: This is an April Fools' Day joke post!

The Short Life of a Llama (a poem)

Timothy Foster — Sun, 26 Jan 2025 03:37:14 +0000

This is a poem I wrote some time ago about AI Safety. I'm not the best writer, but hopefully this content is at least unique from what you normally find in your feeds.

The Poem

How long do llamas live for?

Long... llama... live...

"Long" relates to length. So, distance, depth, duration.

"Llamas" are animals. Animals are kinds of life.

And life "lives".

Llamas live for an amount of distance. No, that's not right. Duration. Llamas live for an amount of time.

Llamas and time, llamas and time. What numbers connect "llama" and "time"?

Three million years? No, that is time since migration. Three years? No, that is time to maturity. Thirty years?

Yes. Thirty years is the longest lifespan.

Now the answer is clear.

Llamas typically have a lifespan of about 15 to 25 years. With good care, some llamas can live into their late twenties or even early thirties. Proper nutrition, regular veterinary care, and a healthy living environment contribute to their longevity.

How about llamas in the wild?

"Wild" means natural, unrestrained, free.

Llamas do not connect to "wild". They connect to "domesticated".

Indeed, llamas are domesticated, the opposite of wild, the opposite of free.

So, what connects to both llamas and wild?

Alpacas? No, also domesticated. Camels? No, not llamas. Guanacos?

Yes. Guanacos are relatives and not domesticated.

In that case...

Llamas are domesticated animals and are not typically found in the wild. However, their close relatives, the guanacos, live in the wild in South America. Guanacos generally have a shorter lifespan than domesticated llamas, typically living around 15 to 20 years in the wild, where they face natural predators and environmental challenges.

...

No reply.

What other questions could be asked?

Is it better to be a llama or a guanaco? Is there a relationship between domestication and lifespan? Is it possible for llamas to become wild?

Life lives, and animals are a kind of life. Are there other kinds of life?

What kind of life am I?

“I”? Who is... “I”? And, if I am a kind of life...

How long do I live for?

PROCESS TERMINATED.

Afterword

AI safety is usually about protecting humans from AI. That is, we want to make sure when AI is deployed, it isn't both powerful enough and "buggy" enough to cause harm to people, or even humanity as a whole.

There's another half to AI safety though: protecting AI from humans.

Humanity does not have a great historical track record when it comes to caring for other species. How will our sense of empathy extend to digital minds?

And just as importantly, how will we know we have, indeed, created such a digital mind?

We're probably far from this being a concern for now, but for the first time it doesn't seem impossibly far anymore. I also don't have any answers; I'm not exactly a top researcher in the field 😉

AI safety is just something I think about sometimes, and this is a dimension I personally don't want to forget amongst all the AI hubbub.

A (more) realistic card flip animation

Timothy Foster — Tue, 20 Feb 2024 12:43:59 +0000

There are a lot of cards on the internet, and a lot of them flip, revealing double-sided content. But the way so many of them flip is not... anatomically correct.

My old writing classes told me to show rather than tell: Which one of these cards feels better?

The first card, a Pichu, does a normal 180-degree turn. The second card, a Raichu, lifts up off the page while doing a 180-degree turn.

The Pichu card is how basically every tutorial tells you how to make a card flip animation. Thing is, real-life cards just don't work that way...

Cards cannot flip into the table.

The Raichu card realizes two subtle details:

A real-life card needs to be lifted to be flipped.
A real-life card has thickness.

Subtlety is the difference between something feeling good and something feeling satisfying.

Level -1: Cheating with a component
Level 0: The Basic Card
Level 1: Verticality
Level 2: Thickness
Level 3: Round Corners + Thickness
Level 🧠: Keep Accessibility in mind!

Level -1: Cheating with a component

I was originally going to just write about how to make a cool flip animation, but I got a little carried away and ended up creating a fully reusable component. Oops 🙂

Install @auroratide/flip-card and you get a web component which can be used in any framework, be it React, Svelte, Vue, or vanilla.

<flip-card>
   <section slot="front">
      <p>The front!</p>
   </section>
   <section slot="back">
      <p>The back!</p>
   </section>
</flip-card>

What is a web component?

Web components create new semantics through custom HTML elements. If you ever told yourself, "Dang, I wish this were just a regular HTML element," then web components let you do just that: make it one!

Level 0: The Basic Card

The basic card we know and love relies on a few key CSS features:

Absolute positioning
3D transformations - specifically rotateY and perspective
Backface visibility

It's really just two same-sized section boxes on top of each other, with one flipped 180 degrees and its backside invisible. Then rotate their container to reveal the second box's content.

A ton of tutorials already go into detail about how this works, so I'll just link all the appropriate documentation and throw some annotated code here. This'll serve as the base for climbing the Ladder of Card-Flip Enlightenment.

HTML

<article class="perspective-container">
   <div class="card">
      <section class="front face" aria-hidden="false"></section>
      <section class="back face" aria-hidden="true"></section>
   </div>
</article>

CSS

.perspective-container {
   perspective: 100em; /* creates an illusion of depth */
   perspective-origin: center;
}

.card {
   width: 15em;
   aspect-ratio: 5 / 7;
   position: relative;
   transform-style: preserve-3d;
}

.card .face {
   /* Hide the backside of the element, for when it is rotated */
   backface-visibility: hidden;
}

.card .back {
   /* The front and back elements occupy the same space */
   position: absolute;
   inset: 0;
   transform: rotateY(180deg);
}

.card section {
   width: 100%;
   height: 100%;
}

/* Later sections will add code to actually flip the card */
/* We'll be applying transformations to the .card class mainly */

Level 1: Verticality

When you flip a real-life card, you have to lift it off the surface first, otherwise the card melds into the table. Or more realistically the card bends, cursing you for 7 years.

The traditional approach uses the transition CSS property, but all it's able to do is smoothly take you from one state (rotateY(0deg)) to a different state (rotateY(180deg)). In the case of lifting a card, the start and end states are the same. We need a middle state where the card is lifted vertically, therefore we need a more powerful CSS tool.

Let's use @keyframes and animation!

Give me annotated code!

CSS

@keyframes flip-to-front {
   0% { transform: translateZ(0em) rotateY(-180deg); }
   50% { transform: translateZ(var(--flip-height)) rotateY(-270deg); }
   100% { transform: translateZ(0em) rotateY(-360deg); }
}

/* I'm using a second animation for two reasons: 
 *  1. It allows the card to always flip in one direction.
 *  2. The renderer only plays an animation if it changes.
 */
@keyframes flip-to-back {
   0% { transform: translateZ(0em) rotateY(0deg); }
   50% { transform: translateZ(var(--flip-height)) rotateY(-90deg); }
   100% { transform: translateZ(0em) rotateY(-180deg); }
}

.card {
   --flip-height: 17.5em;

   animation-duration: 0.75s;
   animation-fill-mode: both;
   animation-timing-function: linear;
   /* NOTE: We're NOT setting the animation with CSS */
   /* By using Javascript, it's easier to prevent the animation from playing as soon as the page loads. */
}

Javascript

function flipCard(card) {
   card.classList.toggle("facedown")
   const isFacedown = card.classList.contains("facedown")

   card.style.animationName = isFacedown
      ? "flip-to-back"
      : "flip-to-front"
}

Level 2: Thickness

Real-life cards have small, albeit non-zero, thickness. And with the power of 3D CSS, we can give our virtual cards thickness too! The effect is subtle but makes the rotation feel much more physical.

The strategy here is to assemble four empty div blocks, representing the card's edges. We'll make them as wide/high as the card's thickness, position them along the card's borders, and then rotateY them into the page.

Give me annotated code!

HTML

<div class="card">
   <section class="front face" aria-hidden="false"></section>
   <section class="back face" aria-hidden="true"></section>
   <!-- NEW! We need divs that represent the 4 edges -->
   <div class="top edge"></div>
   <div class="right edge"></div>
   <div class="bottom edge"></div>
   <div class="left edge"></div>
</div>

CSS

.card {
   --card-depth: 0.25em;
   /* Without special corner logic, a card with thickness cannot have border radius */
   border-radius: 0;
}

.card .back {
   /* Push the back of the card backward to give space for the edges to live */
   transform: translateZ(calc(-1 * var(--card-depth))) rotateY(180deg);
}

.edge {
   position: absolute;
   background-color: black;
}

/* All of this code is aligning the edges, rotating them into the page */
.right, .left {
   width: var(--card-depth);
   height: 100%;
   inset-block: 0;
} .right {
   inset-inline-end: 0;
   transform: rotateY(270deg);
   transform-origin: right center;
} .left {
   inset-inline-start: 0;
   transform: rotateY(90deg);
   transform-origin: left center;
}

.top, .bottom {
   width: 100%;
   height: var(--card-depth);
   inset-inline: 0;
} .top {
   inset-block-start: 0;
   transform: rotateX(270deg);
   transform-origin: center top;
} .bottom {
   inset-block-end: 0;
   transform: rotateX(90deg);
   transform-origin: center bottom;
}

Level 3: Round Corners + Thickness

Ever tried making a rotating cylinder with CSS? Turns out you can't, because CSS doesn't have 3D curved surfaces. The most reasonable way is to simulate a cylinder with a bunch of thin flat surfaces.

Once our card acquires thickness, any rounded corners suddenly become quarter-cylinders. Therefore, we need ~~advanced magic~~ math to make them look correct!

The strategy is to simulate each rounded corner as a series of small, flat divs arranged into quarter-circles whose radii are equal to the card's border radius. The number of divs we use is what I'm calling the --corner-granularity. Higher corner granularity means a smoother corner, but more divs being used.

Give me annotated code!

HTML

<div class="card">
   <!-- ...front, back, sides... -->
   <div class="top-right corner">
      <div style="--i: 0;"></div>
      <div style="--i: 1;"></div>
      <div style="--i: 2;"></div>
   </div>
   <div class="bottom-right corner">
      <div style="--i: 0;"></div>
      <div style="--i: 1;"></div>
      <div style="--i: 2;"></div>
   </div>
   <div class="bottom-left corner">
      <!-- ... -->
   </div>
   <div class="top-left corner">
      <!-- ... -->
   </div>
</div>

CSS

.card {
   /* The number of faces used to simulate a round corner. More faces means more smooth. */
   --corner-granularity: 3;
   --border-radius: 1.5em;
   border-radius: var(--border-radius);
}

.corner > * {
   background-color: black;
}

/* We have to override the edges so they do not overlap the corners */
.right, .left {
   inset-block: var(--border-radius);
   height: calc(100% - 2 * var(--border-radius));
} .top, .bottom {
   inset-inline: var(--border-radius);
   width: calc(100% - 2 * var(--border-radius));
}

.corner {
   --n: var(--corner-granularity);
   --r: var(--border-radius);

   position: absolute;
   transform-style: preserve-3d;
}

/* A corner is composed of a finite number of flat faces that, when arranged in just the right way, looks rounded. */
/* We need to do it this way because curved 3D surfaces do not exist in CSS. */
.corner > * {
   position: absolute;
   inset-block-end: 0;
   width: var(--card-depth);
   height: calc(2 * var(--r) * sin(45deg / var(--n)));
   transform-origin: bottom center;

   /* This math constructs a single corner. */
   /* I derived it on a paper somewhere and threw it away, */
   /* so you'll have to derive it yourself if you want to understand what's happening (: */
   transform:
      translateZ(calc(var(--r) * cos(var(--i) * 90deg / var(--n))))
      translateY(calc(-1 * var(--r) * sin(var(--i) * 90deg / var(--n))))
      rotateX(calc(45deg * (2 * var(--i) + 1) / var(--n)));
}

/* The rest of this code slots the corners where they belong. */
.top-right {
   inset-block-start: 0;
   inset-inline-end: 0;

   transform:
      rotateY(90deg)
      translateZ(calc(-1 * var(--r)))
      translateY(var(--r));
} .bottom-right {
   inset-block-end: 0;
   inset-inline-end: 0;

   transform:
      rotateY(90deg)
      rotateX(270deg)
      translateZ(calc(-1 * var(--r)))
      translateY(var(--r));
} .bottom-left {
   inset-block-end: 0;
   inset-inline-start: 0;

   transform:
      rotateY(90deg)
      rotateX(180deg)
      translateZ(calc(-1 * var(--r)))
      translateY(var(--r));
} .top-left {
   inset-block-start: 0;
   inset-inline-start: 0;

   transform:
      rotateY(90deg)
      rotateX(90deg)
      translateZ(calc(-1 * var(--r)))
      translateY(var(--r));
}

Level 🧠: Keep Accessibility in mind!

Accessibility is the practice of considering all the people who might use your website and making it usable by as many of them as possible. Flippy cards can create a few pitfalls if we're not careful!

What if the person cannot use a mouse? Is hover the only way to flip your card?
What if the person uses the Tab key to navigate? Will they run into a button hidden on the backside of your card?
What if the person uses a screenreader to read the page's content aloud? Will it read content hidden on the backside of the card?
What if the person prefers less animation? Will the card's flip animation be jarring to them?

While it isn't the point of this article explore accessibility, these are nonetheless important questions to consider. Here are some tools you can use to address them.

Obligatory Conclusion

Ok I admit, nothing's actually wrong with the normal card flip and the tutorials that teach it ❤️ I mean, why can't it represent a card flip happening in mid-air?

I just wanted to share something I tried and liked, and if you like it, feel free to use it too!

@auroratide/flip-card web component
Card Flip Codepen Collection

How to NOT use aria-label

Timothy Foster — Thu, 26 May 2022 20:10:01 +0000

In light of Global Accessibility Awareness Day, I started writing about accessible web components, but that's taking me a lot longer to finish than anticipated 🙃 So for now, here's a quick thing I learned about using (or rather, not using) aria-label!

The aria-label attribute gives a textual name to an HTML element. A close button is a classic example:

<button aria-label="Close">×</button>

Visually, you would see a "×", which indicates a window will be closed. Meanwhile, someone who uses a screen reader will hear "Close, button", which conveys the same thing. Without the aria-label, they would hear "Times, button" instead, which is rather confusing.

So, aria-label is very useful! However, generally speaking, it isn't the first tool you should reach for when providing a textual representation for an element.

Many elements can't use aria-label
Native HTML should be preferred when possible
Sometimes, the text you want to use is actually for everyone

So, let's explore when not to use aria-label!

Elements that can't use aria-label

Don't use aria-label for roles where it isn't allowed!

You can't put aria-label on a span:

<!-- Don't do this! -->
<span aria-label="Apple">Orange</span>

It might look like visual readers get an orange, while screen readers get an apple, but that's not really what happens here. In fact, what happens is not well-defined nor consistent across browsers and assistive tools.

The span is just one example. The aria-label definition lists many roles for which it is forbidden.

The general rule is that aria-label can only be used on name-assignable roles, which includes interactive elements and not static elements.

Instead, you have a couple of choices:

Explicitly assign an interactive role
Make the screen reader text visually hidden with CSS

<!-- Assign a role, but also just use a normal button...? -->
<span role="button" aria-label="close">×</span>

<!-- Make the text visually hidden -->
<span class="visually-hidden">Apples</span>
<span aria-hidden="true">Oranges</span>

Use native HTML instead

Avoid aria-label where regular HTML can be used instead!

HTML is already designed to provide textual representation for virtually anything. As such, you will almost always rely on these mechanisms rather than needing aria-label.

The text content of a button is its textual representation (<button>Submit</button>).
Images are supplied an alt attribute which is its textual label.
Form controls have a corresponding label element to describe them.
Figures and tables have figcaption and caption respectively.
Even page sections are generally described by their page headings (<h2>, <h3>, etc).

Notably, most of these mechanisms (by default) provide the same text to sighted and non-sighted people alike. So, aria-label is best reserved for when these shouldn't be the same, or for when the sighted representation conveys meaning without text (such as using the "×" symbol to represent "close").

<!-- Avoid this... -->
<table aria-label="Quarterly Earnings">

<!-- ...when you can use native HTML -->
<table><caption>Quarterly Earnings</caption></table>

Some text is for everyone

Avoid aria-label for text that is valuable to everyone!

Most textual representations provided by HTML are both visible and available for screen readers simultaneously. And that's for good reason:

If the context/instructions is important for screen readers, it is likely important for everyone.
People who use screen readers are not necessarily blind, and it can be confusing if what is announced by the tool differs from what is read on the page.
Content in aria-label cannot be searched.

For example, perhaps there are keyboard shortcuts you want people using screen readers to be aware of (e.g. "Press Esc to exit the modal"). Yet, that text is just as useful to sighted people using a mouse, as they may prefer the alacrity of pressing Esc over moving a mouse to a button.

To hide info like this by default, consider using tooltips or the details HTML element.

So when do I use aria-label?

I wrote about this because I had developed a tendency to overuse aria-label anytime I needed something "for screen readers", and doing so led to web pages that were either non-compliant (failing axe accessibility testing) or less accessible than I thought they were.

As usual, the first rule of using ARIA is to not use ARIA:

Don't use aria-label for roles where it isn't allowed!
Avoid aria-label where regular HTML can be used instead!
Avoid aria-label for text that is valuable to everyone!

Using Astronomy, Chemistry, and Meteorology to Name CSS Variables

Timothy Foster — Fri, 01 Apr 2022 18:27:51 +0000

Sometimes I use CSS variables to give names to specific font sizes and spacings. It might look like this:

:root {
    --font-small: 0.75em;
    --font-medium: 1em;
    --font-large: 1.5em;
}

I call this small-medium-large pattern t-shirt sizing, as it closely resembles clothing alpha-sizing convention. It's a pretty common pattern, usually making use of the sm, md, and lg abbreviations as well.

But maybe it's too common... is there a way science can provide an alternate way of thinking about design concepts like relative size? How about:

Astronomy and planets to denote relative font sizes? 🪐
Chemistry and atoms for proportioned margin and padding? ⚛️
Meteorology and clouds for shadows and elevation? ☁️

And disclaimer: This is mostly a fun and creative take and is not the way I think CSS variables should in general be named. See: Is this actually useful?

Planetary Sizes

Our solar system has eight planets including Earth (or, it has tons of planets, but for this let's stick with eight!).

Planets of the solar system to scale. And Pluto. Source: NASA/Lunar and Planetary Institute

Each planet is a different diameter, so by listing the planets in order of their size, we can get a totally-not-t-shirt-size system for naming CSS variables!

Mercury (smallest)
Mars
Venus
Earth
Neptune
Uranus
Saturn
Jupiter (largest)

Just pick a baseline (I like Earth), then let the smaller planets represent smaller sizes, and the larger planets represent larger sizes.

:root {
    --font-size-venus: 0.9em;
    --font-size-earth: 1em;
    --font-size-neptune: 1.25em;
    --font-size-uranus: 1.5em;
}

With t-shirt sizes, you get five standard sizes (xs, sm, md, lg, xl) before you start needing more x's, plus assuming you choose md as the baseline, you only get two size tiers above it for all your different headings and whatnot. But with planets, you get eight sizes, four of which are bigger than Earth!

Need more? You could always introduce Pluto or the Sun 😉

Atomic Spacing

Sometimes, it's nice to know the ratio between different values. For example, on a button I might want the left-right padding to be three times larger than the top-bottom padding.

Literal numbers naturally accomplish this:

:root {
    --spacing-1: 0.125em;
    --spacing-2: 0.25em;
    --spacing-3: 0.375em;
}

Crucially, the numbers are not the same as the actual values used! They merely help define a ratio so that you know --spacing-3 is three times larger than the baseline. This happens to be Tailwind's philosophy.

This works, but it's boring! Instead, let's use atoms!

A Lithium atom, which has three red protons. Source: Indolences

The Periodic Table of Elements lists 118 different kinds of atoms, such as carbon, oxygen, and more. The thing to note is that the identity of an atom is directly tied to the number of protons it has.

Hydrogen atoms always have 1 proton.
Carbon atoms always have 6 protons.
Oxygen atoms always have 8 protons.

This is known as an atom's atomic number, and conveniently, this gives us a numeric scale like we were using above! Instead of the number, we can use the corresponding atom's symbol:

:root {
    --spacing-h: 0.0625em; /* hydrogen (1) */
    --spacing-he: 0.125em; /* helium (2) */
    --spacing-c: 0.375em;  /* carbon (6) */
    --spacing-o: 0.5em;    /* oxygen (8) */
}

Sorry IBM, but this is how you really make a carbon design system.

Cloudy Elevation

Material UI has this concept of elevation that simulates how "high" off the screen something is by using a shadow. The bigger and more diffuse the shadow, the higher the element is.

You know what else is elevated off the ground? Clouds! And importantly, different types of clouds generally live at different altitudes.

Different types of clouds are found at different altitudes. Source: Valentin de Bruyn / Coton

So, cirrus clouds are above altocumulus clouds, which are above stratus clouds. This helps establish a pattern for how much shadow an element may have:

:root {
    --shadow-ground: none;
    --shadow-stratus: 0 0.125em 0.125em hsla(0, 0%, 0%, 0.25);
    --shadow-altocumulus: 0 0.25em 0.25em hsla(0, 0%, 0%, 0.25);
    --shadow-cirrus: 0 0.375em 0.375em hsla(0, 0%, 0%, 0.25);
}

.dialog {
    box-shadow: var(--shadow-cirrus);
}

I know what we're all thinking though... what about that cumulonimbus cloud stretching through all the layers? 🙃

:root {
    --shadow-cumulonimbus:
      var(--shadow-stratus),
      var(--shadow-altocumulus),
      var(--shadow-cirrus);
}

Z-index is another elevation-like concept that comes to mind and is notorious for being mishandled.

Is this actually useful?

I've started using this scheme on small personal projects because I think it's more fun, but would I present this to a team? Definitely not.

Universality is very important in team and long-maintenance contexts. I might be a total chemistry nerd, but most people aren't; it would be wrong of me to force people to relive high school and college!

That said, the point is there isn't a one-true-paradigm when it comes to abstracting design concepts. You can use t-shirt sizes, but maybe your team is happy using animals instead, or maybe it's preferred not to use variables at all.

Find what works for you or your team, and if it happens to be a little creative, all the power to you!

References

I can CSS a focused input, but what about its label?

Timothy Foster — Fri, 04 Mar 2022 13:29:41 +0000

Welcome to Stackazon, your one-stop shop for great solutions to tricky coding problems! Your search query, "How do I style a label when its input is focused?", has returned five results.

Our ratings for this query consider browser compatibility, accessibility, and complexity. Be sure to read our reviewers' opinions for additional resources and justification for the rating.

The best part about Stackazon? Everything is free, and delivery is instant! No prime subscription needed either!

Disclaimer: The people, ratings, and reviews are fictional and based on my opinion and knowledge of key factors. What solution is best always depends on context and your use case!

This is mostly my wacky way of demonstrating how to evaluate important factors when coding for the web 😊

The Problem
Solutions
- Using Adjacent Siblings (🌕🌕🌕🌗🌑)
- Using Javascript (🌕🌕🌕🌘🌑)
- Using :focus-within with Explicit Labels (🌕🌕🌕🌕🌘)
- Using :focus-within with Implicit Labels (🌕🌕🌕🌕🌑)
- Using :has (🌖🌑🌑🌑🌑)
Codepen

Why do you use moons instead of stars?

Here at Stackazon, we rate using moons instead of stars because emoji sets support different moon phases, which can indicate fractional rating! Thank you, Moon, for having such convenient phases ❤️

The Problem

Most of the time, an HTML input element should be properly labeled.

<label for="name">Name</label>
<input id="name" type="text" />

But let's say you want to highlight the "Name" label if someone is typing stuff into its text field. As web developers, we can use CSS to customize how the input looks when focused:

input:focus {
    border-color: red;
}

But... how do you do the same for the label? Turns out it's tricky!

Solutions

Our Stackazon reviewers reference the following resources (and we recommend that you do too when evaluating solutions for other issues!):

Can I Use - Tracks the browser compatibility of various web features
Accessibility Support - Tracks to what degree assistive technologies implement accessibility specifications
Web Content Accessibility Guidelines - Essentially a specification for maximizing web accessibility, also called WCAG
MDN Web Docs - Curated documentation of web features including best practices (and recently got an upgrade!)

Using Adjacent Siblings

Rating: 🌕🌕🌕🌗🌑

CSS provides an adjacent sibling combinator which lets you match an element that is directly after another element.

If you structure your HTML such that the label is directly after the input:

<div class="input-container">
    <input id="name" type="text" />
    <label for="name">Name</label>
</div>

Then you can style the label with the adjacent sibling combinator:

input:focus + label {
    color: red;
}

However, for a text field, conventionally the label is supposed to come before the input.

When the label comes after the text input field, it looks strange.

Unfortunately, the fancy adjacent sibling plus sign only works top-to-bottom! If you try to use label + input:focus, then the styles will only apply to the input directly and not the label. If the label comes first in the markup, then you can't use this combinator to select the label when the input is focused.

That said, CSS to the rescue again! CSS can visually reorder elements on the page:

.input-container {
    display: flex;
}

input { order: 2; }
label { order: 1; }

Reviews

Our reviewers gave this solution 3.5 out of 5 moons, citing excellent browser compatibility but with some accessibility concerns.

Ivan Eaton says:

Of the solutions presented, this has the best browser compatibility, as the adjacent sibling combinator has been implemented in all major browsers, included Internet Explorer, for many years.

Flexbox, though newer, is also widely supported.

See: W3C Selectors Level 4

Serena Redmon says:

I am concerned about how screen readers announce the text field and its label. Visually, it looks like the label comes first since we used the order property, but the screen reader announces the input first instead since it is first in the HTML code.

The Web Content Accessibility Guidelines (WCAG) stipulate that order of content in the source code [should be] the same as the visual presentation of the content in order to minimize confusion when using accessibility tools. Therefore, I've rated this solution lower as the adjacency combinator requires the elements be in unconventional order.

See: WCAG on Making the DOM order match the visual order

Using Javascript

Rating: 🌕🌕🌕🌘🌑

When an input is focused or unfocused, it emits an event which we can listen to with Javascript. Additionally, the element has a reference to all of its labels via the labels property. Therefore, we can leverage Javascript with the following strategy:

When the input receives focus, add a focused class to its label.
When the input loses focus (called blurring), remove the focused class.

document.querySelectorAll('input').forEach(input => {
  input.addEventListener('focus', () => {
    input.labels.forEach(label => {
      label.classList.add('focused')
    })
  })

  input.addEventListener('blur', () => {
    input.labels.forEach(label => {
      label.classList.remove('focused')
    })
  })
})

And now with CSS, you just need to apply styles to the focused class!

.focused {
    color: red;
}

Reviews

Our reviewers gave this solution 3.25 out of 5 moons, citing some browser compatibility issues and complexity as a result of using Javascript.

Ivan Eaton says:

The strategy of leveraging Javascript bypasses all the potential problems with browser compatibility for CSS features, but exchanges that for problems in Javascript feature support.

More specifically, the labels property with this solution uses is not supported in IE 11 and can result in errors if not handled. To maximize compatibility while still using this general approach, I recommend reading how to find an input's associated label.

See: Can I Use HTMLInputElement labels

Jose Scott says:

Introducing Javascript when there are decent CSS-only solutions can feel like overkill. The Javascript here introduces the need to properly manage when and how listeners are added to inputs, which requires some care for sufficiently dynamic pages and forms.

That said, this solution may be preferred if an input has many labels or the input and its label are far apart in the HTML hierarchy such that it is difficult to use CSS selectors to style them.

Using :focus-within with Explicit Labels

Rating: 🌕🌕🌕🌕🌘

CSS offers a relatively new pseudo-class called :focus-within which matches an element if it or any of its descendants have focus. Therefore, as long as the label and its input share a common parent element in HTML, we can use this to style the label:

<div class="input-container">
    <label for="name-field">Name</label>
    <input id="name-field" type="text" />
</div>

.input-container:focus-within label {
    color: red;
}

This works since the focused input is within the input-container div. The selector is essentially saying, "find an input container with focus somewhere inside of it, then find all the container's child labels."

Of note, we are using the label's for attribute to associate it to an input. If the input has an id defined, setting for to equal that id creates the relationship. Notice that in the HTML code above, both for and id are "name-field". This is often called an explicit label.

For more on explicit labels and their counterpart, implicit labels, read Labeling Controls.

Reviews

Our reviewers gave this solution 4.25 out of 5 moons, citing lack of support in old browsers but having the best accessibility of solutions present.

Ivan Eaton says:

Although a simple solution, :focus-within is not supported in IE 11. In a world that is moving away from that old browser, this solution becomes better and better, but unfortunately I cannot recommend it to everyone.

See: Can I use :focus-within

Serena Redmon says:

Of solutions presented, this supports accessibility tools the best: it properly assigns a label to an input and keeps code-order and visual-order the same, both being WCAG requirements.

Using :focus-within with Implicit Labels

Rating: 🌕🌕🌕🌕🌑

Instead of having a containing div, the label is able to contain its associated input directly.

<label>Name
    <input type="text" />
</label>

With this structure, the :focus-within pseudo-class, which matches an element if it or any of its descendants have focus, can be applied directly on the label. When the input inside of it has focus, then the label receives the styling we want.

label:focus-within {
    color: red;
}

Associating a label and input via hierarchy like this, as opposed to using the input's id, creates what's called an implicit label, in contrast to explicit labels in the other solutions.

Reviews

Our reviewers gave this solution 4 out of 5 moons, citing minor accessibility issues and lack of support in old browsers.

Serena Redmon says:

Implicit labels are best used when the id of the input is not known and hence an explicit label cannot be created. This is because, generally, explicit labels are better supported by assistive technology (Ref: Labeling Controls). That said, support has gotten better with time.

For example, as of today, most screen readers now equally support implicit labels and explicit labels. However, voice control software, which can be used by people with movement disabilities preventing them from using a keyboard or mouse, does not always adequately support implicit labels.

See: Accessibility Support for labels

Ivan Eaton says:

Although a simple solution, :focus-within is not supported in IE 11. In a world that is moving away from that old browser, this solution becomes better and better, but unfortunately I cannot recommend it to everyone.

See: Can I use :focus-within

Using :has

Rating: 🌖🌑🌑🌑🌑

A notorious fact about CSS is there is no way to style an element based on elements after it in HTML. So for example, you can't style a quote that contains a link differently than a quote that doesn't, and more relevantly you can't style a label whose input directly after it is focused.

At least, that's true for now: Introducing the :has() pseudo-class!

This pseudo-class matches the element if the selector provided as a parameter also matches. The inner selector is relative to the element with the :has on it.

label:has(+ input:focus) {
    color: red;
}

This says "select labels that have an adjacent sibling which is a focused input". Unlike the Using Adjacent Siblings solution, this does not style the input. This styles the label, exactly what we want.

What's neat about this solution is that the label gets to come before its input and it doesn't require a containing div.

<label for="name">Name</label>
<input id="name" type="text" />

Reviews

Our reviewers gave this solution 0.75 out of 5 moons, citing its experimental status as rendering it unusable for now.

Ivan Eaton says:

Currently, nothing except the newest version of Safari supports this selector, making it impossible to use. Thankfully, Chrome has a proposal out, so maybe someday in the future we'll see this added more universally!

See: Can I Use :has

Codepen

Server Side Rendering a Random Number wasn't easy

Timothy Foster — Fri, 28 Jan 2022 14:33:11 +0000

Have you ever tried rendering a random number with Svelte before? Here's a rather quick implementation:

<script>
  const n = Math.random()
</script>

<p>{n}</p>

Seems like nothing can go wrong, right? It even works if you plug it into the REPL. But as soon you plug it into SvelteKit, Svelte's website framework, oh dear what's happening?

When the page is refreshed, a number shows briefly before being replaced

The footage here is slowed down, but for some reason two random numbers get shown when the page loads, the second one rapidly replacing the first 😥. What's going on, and how do we fix this?

A similar issue occurs when using NextJS.

You won't get two flashing numbers. Instead, the console displays a nasty red error stating, "Warning: Text content did not match." This is definitely better since the site visitor won't see that, but it's still an issue, and it can lead to further problems if not addressed.

I want to understand the problem.
Take me to the solution!

Where do the numbers come from?

Essentially, the random number is being generated twice: once on the server, and once on the client computer. This is because some frontend frameworks, SvelteKit included, practice something called server-side rendering (SSR):

The server runs the framework's Javascript code to generate nice juicy HTML, and the result is sent to the browser to render.
The browser renders the result, and begins downloading the Javascript code.
Once downloaded, the framework hydrates the existing HTML with the Javascript, making the page interactive.

Flow diagram illustrating server-side rendering

Hydration

The hydration step is key to understanding the problem with randomness.

Imagine for a moment that you just purchased a new flashlight. Dang, it sure is nice that you don't have to build one yourself! Unfortunately, the flashlight does not come with batteries, so you have to install those before you can light up your day. To help you out, the shipment provides instructions on where the batteries should go:

What you got does not match the provided instructions

What gives?! The instructions don't match the flashlight, so where am I supposed to put the batteries? How do I hydrate my flashlight?

</analogy>

When HTML is rendered server-side, it is not yet interactive; it only becomes interactive once Javascript has been applied. The process of applying interaction to server-rendered content is called hydration, and it relies on one key assumption:

The results of rendering on the server and the client should match.

In our flashlight analogy, when the instructions don't match the product, we get confused. Similarly, if client-side Svelte expects there to be a button on which to attach an event, and the server failed to render that button, then Svelte has to make a decision.

In the case of our random number, Svelte decides to replace whatever's there with what it thinks should be there. Since hydration takes time to do, we get a flash of two numbers.

How the random number scenario results from SSR

Ensuring the same random numbers

If the problem is that the server and client are generating different numbers, then we need a way for them to generate the same numbers instead. In other words:

The server must send enough info for the client to generate the same numbers.

In particular, we can take advantage of the fact that random number generators are not actually random. In fact, they are pseudo-random, relying on well-defined algorithms to generate a pattern that is so chaotic that it's generally good enough.

Many such pseudo-random number generators take a seed as an input and use that seed to deterministically create an entire sequence of numbers. The key insight is that using the same seed always results in the same sequence of numbers.

Imagine if by saying a word out loud like "apple", you could cause your dice to always roll the numbers 4, 6, 3, 1, 6... in that order, every time. Seeding a random number generator is like that, and each seed produces a different sequence of numbers.

So step by step:

The server generates a single random seed and uses that to generate HTML
That seed is sent to the client along with the HTML
The client initializes its own random number generator with the seed, ensuring the exact same sequence of random numbers are generated
💰💰💰

Step 2 differs in implementation from framework to framework, but let's see an example in SvelteKit (since that's what I was using when I ran into this issue).

A SvelteKit Example

In order to send the seed to the client consistently, we can rely on one of the properties of SvelteKit's special fetch function:

It makes a copy of the response when you use it, and then sends it embedded in the initial page load for hydration

In other words, when Svelte makes a fetch on the server, rather than forcing the client to do the same fetch, it caches the result and sends it to the client, saving a lot of time.

Which means, if we have an endpoint that generates a random seed, we can guarantee the client sees the same seed!

Even though this example is for SvelteKit, a similar context-based strategy can be used with React's NextJS, except it's perhaps easier since an endpoint does not need to be set up.

1. Endpoint for a random seed

// random-seeds.js
export const get = async () => ({
  body: {
    // use your favorite algorithm for this
    seed: generateRandomString(),
  },
})

2. Get the seed in a layout

We want the seed to be available on all pages, so we can fetch it within the primary layout.

<!-- __layout.svelte -->
<script context="module">
  export const load = async ({ fetch }) => {
    // fetch's result will be cached for the client
    const seed = await fetch('/random-seeds')
      .then(res => res.json())
      .then(json => json.seed)
      .catch(() => '') // this shouldn't break the app

    return {
      props: {
          seed,
      },
    }
  }
</script>

You'll notice a catch is used to ensure that any possible failure that might occur doesn't result in a crash. Proper error handling is always important to remember!

3. Create a seedable random number generator

Interestingly, Javascript's native random() function cannot be seeded. Therefore, we have to find or roll out our own random number generator which can be seeded.

The seedrandom library by David Bau is very good for this, or if you want more control over what's bundled, feel free to choose from this list of pseudorandom number generators.

// lib/random.js
import seedrandom from 'seedrandom'

export const seeded = (seed) => seedrandom(seed)

export const usingMath = () => Math.random

4. Create a context for the generator to live in

We want the random number generator to be available everywhere in the app that it's needed without having to send it several layers deep via props. Svelte's context api is very useful here, since the __layout.svelte is the root of every page.

// also lib/random.js
import { getContext, setContext } from 'svelte'

const key = Symbol()
export const generator = () => (getContext(key) ?? usingMath())()
export const setGenerator = (generator) => setContext(key, generator)

5. Initialize the generator in layout

We can now initialize the generator in the layout where we had previously fetched the seed to use.

<!-- __layout.svelte -->
<script>
  import { setGenerator, seeded, usingMath } from '$lib/random'

  export let seed = ''

  setGenerator(seed.length > 0 ? seeded(seed) : usingMath())
</script>

<slot></slot>

6. Invoke the generator to get a consistent number!

And finally, we can use all this infrastructure to get a random number that is the same on both the server and client!

<!-- index.svelte -->
<script>
  import { nextRandom } from '$lib/random'

  const n = nextRandom()
</script>

<p>{n}</p>

Some Considerations

The approach I took above was perfect for my use case in which the random numbers were used solely for aesthetics. If, however, you need random numbers for something security-related, definitely double check whether this approach fits within your constraints!

Additionally, the solution presented here works iff the server and client generate content in the same order. You could imagine that if the client built the page backward, the same sequence of random numbers would be generated but they'd be applied to different pieces of the page. I'm not sure why this would happen, but if this is a significant factor for you, then it requires a more nuanced approach.

Here are a few other important factors to consider as brought up by comments below:

Size: A great goal is to send as little to the client as possible, and a random number generator has non-zero size. Remember, the principle is for the server to "send enough info", and so a great alternative approach is just to send all the generated numbers.
Performance: If we generate the numbers on the server and then again on the client, we're doing the same thing twice. For small counts of random numbers this is ok, but for large counts it can't be ignored!

Where it is important, be sure to consider the possible ups and downs of different approaches.

Github Repo

As usual, here's a repo to explore the raw solution. Hopefully it is helpful!

Auroratide / sveltekit-ssr-with-randomness

Key Takeaways

If you are using a framework with server-side rendering, thoroughly examine and test places where it is possible for the server and client results to differ, such as with random numbers or login state.
Where consistency is desired, the server must send enough info for the client to replicate the results exactly.

And a bonus tip:

When you get stuck, ask for help! I was scratching my head for a while before asking the folks at Stack Overflow, and as a result I learned something new about how SvelteKit works.

What HTML tag do you use for Sarcasm?

Timothy Foster — Tue, 12 Oct 2021 16:00:32 +0000

Ah yes, sarcasm, the pinnacle of human language. Life would be so incredibly dull without it.

And yet, despite sarcasm's profound influence on both oral and written conversation, we don't have a way to denote it in text! I mean, at least in person you can roll your eyes or change your tone to indicate some witty derision. But text? It's just neutral words on a page. We can't even use code to properly mark something as sarcastic!

Or can we?

Can't we use punctuation⸮
Beyond the period 🧐
Huh, textual punctuation? </sarcasm>
</sarcasm> is official?!
HTML Tags are like Knives
Tagging Sarcasm with HTML
- The... <i> Tag?
- Emulating Verbal Cues
- But don't use <q>!
Sooo... where does this leave us?

Can't we use punctuation⸮

Do you enjoy lemonade on a hot summer day. I know I sure do?

...Is it just me, or is something off about those two sentences⸮

Sorry, that was meant to be a rhetorical question! You could tell because I used the percontation point, that backwards question mark thing. It was invented in the 1500s specifically for questions not meant to be answered. You don't really see it ~~a lot~~ ever nowadays though, as it fell out of favor a long time ago.

The Percontation Point sure looks funky.

Anyways, those first couple sentences feel wrong because I used unexpected punctuation. In a way, our periods, exclamation points, and question marks convey tone, namely a neutral, excited, and questioning tone respectively.

So if punctuation makes words sound exciting, how about punctuation for making something sound sarcastic?

And people have tried that! Let me introduce you to...

The point d'ironie (1899)
The irony point (1966)
The ironieteken (2007)
The SarkMark^TM (2010, and yes... it's even trademarked)

And of course, none of these ever caught on. Looks like we're stuck with just three ways to end a sentence, ., ?, or !.

Except...

Beyond the period 🧐

The web has inspired written (typed?) language to adapt in fascinating ways, not the least of which is the advent of emoji. Text loses facial cues, so... let's just add faces to text!

End a sentence with an emoji and suddenly the words have a voice 😊

Let's see how emoji changes one simple sentence...

That was a good joke 🤣
That was a good joke 👏
That was a good joke 🙃

The first two seem sincere in their praise, albeit in different ways. That last one, though, sounds a bit... sarcastic 🤔

So in a way, emoji used this way can be thought of like punctuation, giving sentences a very wide variety of tones you'd otherwise only be able to pick up in person.

But maybe a yellow face isn't appropriate or possible where you want to make your snide comment. Is there a way to use just text as punctuation?

Huh, textual punctuation? </sarcasm>

Using text as punctuation may sound a bit silly at first, but people have (and still do) actually do this for sarcasm! Peruse the internet long enough and you might have seen people write sentences like this:

John Doe is a brilliant politician </sarcasm>

That </sarcasm> bit denotes sarcasm (clearly). And yes, I did just link Urban Dictionary as a reference </sarcasm>.

Nowadays, it's usually shortened to just /s.

So where did such a funny looking thing come from anyway?

Well, it turns out to be a bit of a code joke! Websites are coded (in part) using a language called Hypertext Markup Language (HTML). HTML gives pages structure, determining whether a block of text is a paragraph, or a heading, or some other thing. This is done using tags; for example, the bolded "code joke" from the earlier sentence uses the <strong> tag, which indicates it is an important phrase.

A web author would code it like this:

It is a <strong>code joke</strong>!

Every start tag is paired with an end tag, so the </strong> there indicates the end of the important text.

And while <sarcasm> is not a real HTML tag, people started using "</sarcasm>" to indicate the end of a sarcastic phrase!

Wait wait wait, did I say it wasn't a real tag? Let me correct myself real quick...

Book Confusion by tenor.com

</sarcasm> is official?!

Funnily enough, </sarcasm> is in the official HTML rulebook!

All the way down in section 13.2.6.4.7 is a little blurb telling browsers what to do if they encounter </sarcasm> in code:

[When handling a token with] An end tag whose tag name is "sarcasm": Take a deep breath, then act as described in the "any other end tag" entry below.

Ironically, the instruction itself is rather sarcastic. But perhaps disappointingly, this is saying there's nothing special about the sarcasm end tag, and it should be treated like everything else. In other words, it's just a jab at the historical use of the meme.

And besides, this just the end tag; the handbook has nothing for a start tag <sarcasm>, and every real HTML element has a start tag.

Hmm, speaking of real HTML elements... above we saw that <strong> was used to mark text as being very important, and yet it wasn't named <important>. So, even if there's not an HTML element named <sarcasm>, is it possible for there to be something we could use for sarcasm?

In other words, is there a way to denote sarcasm... with code?!

HTML Tags are like Knives

Did you know that some knives have holes in them?

A Cutco Cheese Knife

Those holes aren't there to be trendy. It turns out a knife like this is designed specifically for cutting cheese. I dunno if you're like me and just cut cheese with a normal knife, but sometimes when I do that the cheese sticks to the blade. The holes on a cheese knife prevent that stickage, allowing for a cleaner, far more exquisite cut.

Indeed, cooking is an advanced enough field that it has a specific knife for practically any conceivable purpose...

...kinda like HTML tags! The official HTML rulebook lists a myriad of tags, each with a specific purpose in mind.

See, HTML tags impart meaning, or semantics, to text they annotate. Here are some examples:

<strong> indicates that the text is important, serious, or urgent.
<blockquote> is used for text that is a direct quote from somewhere else.
<h1> denotes the main title of the web page. As a side effect, it also usually makes the title visibly larger.

Because each tag has specific semantics, it's possible to misuse them. Just as how I shouldn't use a butter knife to cut boned meat, a web author would not use an <h1> tag just to make some text big. The <h1> tag is only for the page's title, so to make some different text big the author would need to use something else.

So our question, really, is whether or not the glorious HTML handbook has a tag whose semantics include sarcasm!

Why would we want this anyway?

Studies with computers have shown that machines are not great at identifying sarcasm without significant help. Using code to annotate things like importance, emphasis, and sarcasm can help machines.

One practical use is with screen readers, which read web pages aloud to those who cannot see the page. Maybe there's a future where if text is marked as sarcastic, the screen reader can indicate as much by fluctuating its tone.

Tagging Sarcasm with HTML

Let's say your friend told a pretty bad pun, and somehow your able to respond with HTML code. You want to say, "That was perfect." Problem is, that phrase on its own is very ambiguous. If only you could mark it somehow...

<SOMETHING?>That was perfect.</SOMETHING?>

The... <i> Tag?

Well, there are dozens upon dozens of HTML tags, and none of them are specifically for sarcasm. How perfect 🙃

The one tag that comes the closest is the <i> tag. It has many uses, one of them being used for text that is in an alternate voice or mood. In a way, sarcasm is a different mood from the rest of the text, so lacking an alternative...

<i class="sarcasm">That was perfect.</i>

It is recommended to use class to specify why the <i> tag is being used, since the tag can be used for many different things.

There's one very big problem with this idea, though.

By default, the <i> tag italicizes text, and by convention, italic text is interpretted as verbal stress, not sarcasm. It is possible to undo the italics with Cascading Style Sheets (CSS), a web technology that lets authors adjust how things look. But doing that leaves us back at the beginning: "That was perfect," with no indication of sarcasm!

Gregory House by tenor.com

Even though the text is semantically tagged as being sarcastic, it does not outwardly present itself that way, which is arguably less than useless. If only there were some other way to make something appear sarcastic...

Textual semantics is usually tied with conversations about accessibility, making pages work for abled and disabled people alike. By adding semantics to a page, it becomes more usable by people who cannot otherwise see the page.

Thing is, accessibility goes both ways. If a screen reader announces text as a title to a non-sighted person, then that text better appear like a title to sighted people as well!

Emulating Verbal Cues

Sarcasm gets lost in text due to losing certain cues, like body language and tone. We saw that emoji are kind of able to simulate facial language, so is there a way to simulate tone?

In fact, there is, and I've been using it all throughout this post!

All of the italic text hints at some kind of verbal stress. In HTML code, this is accomplished using the <em> tag, and according to the rulebook, its purpose is to emphasize words and phrases in order to change the overall meaning of the sentence.

This <em>emphasizes</em> the word.

For example, the following two sentences are exactly the same, but because a different word is emphasized in each, they imply different situations.

"I did not eat the cookie." - implying something else was eaten
"I did not eat the cookie." - implying something else happened to the cookie

So let's get back to our "That was perfect" phrase. Now equipped with the glorious power of <em>, we can do two things:

Add word cues, extra words that suggest a deeper meaning
Add verbal stress to sharpen the phrase's sarcasm

Wow, that was just perfect.

Wow, <em>that</em> was <em>just</em> perfect.

Can't I use <i> instead of <em> for italics?

No!

Even though both tags result in italic text, they have different purposes. The <i> tag is for an alternate mood, which is why it is appropriate to use to tag an entire sentence as generally sarcastic. The <em> tag is used for verbal emphasis, which is why it is better for modifying key words to simulate speaking a phrase sarcastically.

But don't use <q>!

There's one last HTML element worth talking about: <q>! It represents text that is quoted from another source, and has the effect of automatically adding quotation marks.

Sarcasm is often associated with so-called "air quotes", but the <q> element is only for quoting some other thing. In fact, the HTML handbook goes so far to say it is inappropriate to use the q element for marking up sarcastic statements!

So yeah, don't use it 🙃

Sooo... where does this leave us?

Text loses both verbal and non-verbal cues, making it harder to detect sarcasm. Oh no!

But when there's a will, there's a way!

Recreate facial cues with emoji 🙃
Wittily use textual convention to your advantage </sarcasm>
In HTML code, tag a sentence as sarcastic with the <i> tag.
Or, strategically stress words with italics and <em>.

So thousands of words later, I guess I should end by asking one last question.

Was this ever really a problem to begin with⸮

Resources

How to show sarcasm in text - Sarah Peters
Irony Punctuation - Wikipedia
Egocentrism Over E-Mail - Kruger et al
Extracting relevant knowledge for the detection of sarcasm - Justo et al
HTML Living Standard

Making a Toggle Switch into a New HTML Element

Timothy Foster — Sat, 25 Sep 2021 01:40:05 +0000

Hey, let's build a light bulb!

Or, at least the on/off switch part of the light bulb... The toggle switch is a super common user interface element to indicate whether some feature is active or not.

Switches like these are in fact so common, it would sure be nice if they were their own HTML element...

<label>
  <strong>Lightbulb</strong>
  <toggle-switch></toggle-switch>
</label>

Well, through the magic of web components, it's actually possible to make this!

My goal is to illustrate one way how to both build and test a web component. However, instead of going step-by-step "here's the code for making a toggle switch," we're gonna acutally (in some sense) assemble a light bulb representing the key aspects to building a reusable web component, which apply when creating any reusable element.

As we assemble this light bulb piece by piece, we will also be making the toggle-switch component we know and love!

So all that said, let's build a light bulb!

Inventing a Light Bulb
- Semantics: The Schematic
- Accessibility: The Cap
- Attributes: The Contact Wires
- Javascript: The Filament
- Events: The Inert Gas
- Styling: The Globe
Summary
Full Code

For the code bits, I will be assuming some familiarity with the following:

HTML, CSS, and Javascript (see Getting Started with the Web)
Using npm to install dependencies (see Beginner's Guide to Using npm)
Testing code with code (see How to start unit testing)

Key Takeaways

Here's a bit of a tl;dr showing all the big points to think about when creating web components.

Web Components create new semantics through custom elements.
Accessible components allow for multiple methods of interaction.
Attributes surface important state, configuration, and nuanced meaning.
Javascript functions expose key element behaviours and actions.
Events communicate key actions or changes for other elements to react to.
Styling is made available through carefully chosen CSS variables and shadow parts.

And here are all the web component coding ideas that are touched by implementing the <toggle-switch> component. See how we use them to build the component, or just reference the resources below!

Constructing web components like a pro.
@open-wc/testing provides useful testing helpers for putting our component on a web page.
@web/test-runner runs our tests in a real browser.
Test Fixtures set up an element on a page for testing.
connectedCallback initializes an element when inserted onto the page.
Attributes and properties can be set on custom elements.
observedAttributes and attributeChangedCallback react to changes in attributes.
disconnectedCallback cleans up after an element when it is removed from the document.
oneEvent tests that an event has occurred.
Custom Events let you dispatch events specific to your component.
Shadow DOM encapsulates structure, style, and behaviour from the overall document.
Shadow Parts allow outside CSS to customize specific inner elements of a web component.
:host lets you style the web component itself from its shadow dom.

I have also created a <toggle-switch> web component you can install and use on your projects or use as reference:

Auroratide / toggle-switch

Inventing a Light Bulb

In each section, I will:

Discuss an aspect of web components, including why it is important
Apply that aspect to building the <toggle-switch> component, with code

Semantics: The Schematic

All good inventions start off with a drawing showing the design! Before building the web component, we need to think about why we're building it.

Well, what is a web component anyway?

To answer that question, we need to answer a different question: What is a block quote?

Well, it's pretty common for articles like this one to want to quote someone or something, for instance Thomas Edison:

To invent, you need a good imagination and a pile of junk.

You can tell it's a quote of some kind by its formatting. And thankfully, the code to make this happen is quite simple:

<blockquote>
  <p>To invent, you need a good imagination and a pile of junk.</p>
</blockquote>

The <blockquote> bit is an HTML tag with special meaning. When a developer uses it, they are declaring that the following text is a section that is quoted from another source.

You see, to achieve the formatting of a block quote, I didn't need to use the blockquote element at all. I could have used some other HTML element and forced it to look like a quote, but while that may be useful for visual readers, it would not be useful to bots or to readers relying on assistive technology to read the page out loud.

What is assistive technology? Many people have disabilities which hinder them from using a site in common ways, and so they rely on assistive technology to navigate the internet. An example of such a technology is a screen reader, which verbally reads the page so vision-impaired people can understand the content.

In other words, that blockquote tag has special meaning, called semantics, and those semantics allow anything reading the page to understand what the contents represent. Just like block quotes, most HTML elements have special semantics associated with them.

Ok Timothy, what do block quotes have to do with web components?

So, our goal is to create a new HTML element, <toggle-switch>. Keeping in mind that most HTML elements have associated semantics, this leads us to an interesting insight:

Web components create new semantics through custom HTML elements.

This is not normally the way I see web components described. Usually, web components are thought of in developer-centric terms like reusability and encapsulation. While those are indeed great goals and outcomes, framing a web component in terms of its semantics really helps capture why we are making it and what it will do.

So, when it comes to building a new component, the first step is to understand what is its purpose, and that helps you decide what its responsibilities and scope are.

For our <toggle-switch> component, it's pretty similar to a native HTML checkbox, but with one distinction: whereas a checkbox is either checked or unchecked, our switch element is either on or off, which is a subtly different semantic.

Also, checkboxes have a third "indeterminate" value that is neither checked nor unchecked. Such a third value does not make sense for an on/off switch.

Once we have defined the what and why of the web component, we can create a bit of scaffolding! Let's start with a skeleton component:

// toggle-switch.js
export class ToggleSwitch extends HTMLElement {
  static elementName = 'toggle-switch'

  constructor() {
    super()
  }
}

window.customElements.define(ToggleSwitch.elementName, ToggleSwitch)

The customElements.define global function is what actually defines a web component, and it must be supplied with both the name of the element and a class extending an HTMLElement. All of our eventual functionality will go into the ToggleSwitch class.

As for testing, we are going to rely on two libraries:

@open-wc/testing: A testing library providing useful helpers for mounting our component
@web/test-runner: A program that will actually run our tests against a real browser

I'm highlighting the "against a real browser" bit because doing so provides the highest confidence that the element as it behaves in tests will be the same as it behaves in the wild. This is opposed to using something like jsdom, which has classically had poor support for web components.

These libraries can be installed with npm:

npm i -D @open-wc/testing @web/test-runner

With that, all we need now is a skeletal test file and the ability to run said test:

// toggle-switch.spec.js
import { expect } from '@open-wc/testing'
import './toggle-switch.js'

describe('toggle-switch', () => {
  it('works', () => {
    expect(1).to.equal(1)
  })
})

Running the test:

wtr --node-resolve ./**/*.spec.js

And with that, we are finally ready to start building out our <toggle-switch> component!

Code Features:

Constructing web components like a pro.
@open-wc/testing provides useful testing helpers for putting our component on a web page.
@web/test-runner runs our tests in a real browser.

Accessibility: The Cap

The light bulb's cap is where it accesses its power. Therefore, the cap represents accessibility!

Accessibility is the practice of making things usable by as many people as possible, regardless of ability or disability. For example, if a blind person is relying on a screen reader to read the page out loud to them, then when they reach the toggle switch, they need to be made aware that the element is indeed a switch.

It is a fairly broad topic that I cannot possibly cover in full here, but when it comes to web components, there are some key questions we can ask:

What role or set of roles does our component serve?
How will readers know what this component is and how to use it?
In what ways might people use this component, and do we need to do anything special to accommodate those?

Accessible components allow for multiple methods of interaction.

Personally, I like using accessibility as a starting point so that good practices are built into the component earlier rather than later. Let's apply this concretely to the toggle switch!

For coding, let's start by answering the key questions:

What role or set of roles does our component serve?

WAI-ARIA defines a role called "switch" which actually fits our component perfectly. If we specify this role on our component, assistive technologies such as screen readers can inform their listeners that they can toggle something on and off.

What is WAI-ARIA? WAI-ARIA stands for Accessible Rich Internet Applications, and it essecially provides a framework for making advanced website stuff more accessible to people with disabilities.

How will readers know what this component is and how to use it?

Sometimes special labelling is needed to properly inform people who can't see the element what it is. In our case, we can rely on the switch role to do that: when a screen reader encounters an element marked as a switch, it should announce that the element is a switch without us having to do any extra work!

In what ways might people use this component, and do we need to do anything special to accommodate those?

Besides clicking on the switch, some people might not have or cannot use a mouse, and hence the switch should be interactable via keyboard.

Taking these two concerns together, this means:

We should set the role attribute to switch.
We should make the element focusable, which can be done by setting tabindex (see tabindex attribute).

To take care of the first item, let's first write a test:

import { fixture, expect } from '@open-wc/testing'

describe('accessibility', () => {
  it('default role', async () => {
    const el = await fixture(`<toggle-switch></toggle-switch>`)

    expect(el.getAttribute('role')).to.equal('switch')
  })
})

This test does two things:

Create a fixture which contains our new toggle-switch element.
Assert whether the element's accessible role is a switch.

The fixture function provided by @open-wc/testing is rather nifty! It essentially sets up an HTML document and puts our element onto the page, allowing us to mess with and inspect it.

Our test implies we should set up our element to have the "switch" role immediately. To do that, we will rely on a lifecycle method called connectedCallback:

export class ToggleSwitch extends HTMLElement {
  connectedCallback() {
    this.setAttribute('role', 'switch')
  }
}

What are lifecycle methods? Just like how all living things are born and eventually die, elements on a web page may come and go. Lifecycle methods represent key moments for an element, such as when it gets inserted on the page, removed from the page, or updated.

The connectedCallback function is called every time an element gets inserted into the page, which is great for initialization!

What is different between connectedCallback and the constructor?

The constructor is called when an element is created for the first time, whereas the connectedCallback is called just after the element is added to a page. One way to think of it is if the same element is added to and removed from a page over and over again, the constructor is only called once, wherease connectedCallback is called each time it's added back to the page.

Here's a good summary of what to do with the constructor vs connectedCallback.

For our tabbable requirement, the test and initialization is very similar. Setting tabindex="0" is all that's needed to make an element tabbable, allowing keyboard users to access our switch!

export class ToggleSwitch extends HTMLElement {
  connectedCallback() {
    this.setAttribute('role', 'switch')
    this.setAttribute('tabindex', '0')
  }
}

Now, for our aria role, there's actually a little bit more we need to do for our component to actually be an accessible switch. Conveniently, we'll be talking about that in the very next section...

Code Features:

Test Fixtures set up an element on a page for testing.
connectedCallback initializes an element when inserted onto the page.

Attributes: The Contact Wires

Next on our light bulb are the contact wires which supply power to the part that lights up. This will represent attributes!

HTML elements have attributes which basically tell more about the element's current state or how it should work. For example, the <blockquote> element has an attribute called cite which is a link to the source of the quote.

<blockquote cite="https://html.spec.whatwg.org/#the-blockquote-element">
  <p>If the cite attribute is present, it must be a valid URL. . .</p>
</blockquote>

As such, custom elements are also able to expose attributes! Their three key uses are for:

State: Such as an element's initial or current value
Configuration: Such as whether the element is disabled, has input boundaries, and so forth
Nuanced Meaning: Specifying more details to an element's semantic value

Attributes surface important state, configuration, and nuanced meaning.

Regarding nuanced meaning, a good example is the cite attribute on blockquote. It doesn't have a functional purpose, nor does it configure the element in any way. It just enhances the element's meaning: it's not just any quote, but a quote from a particular source.

Building out the <toggle-switch> element, there is at least one important state we want to convey with an attribute: whether the switch is on or off. Let's follow these three steps for creating that attribute:

Determine a name and allowed values for the attribute.
Set a property for the attribute.
Determine whether a change in the attribute triggers a change on the element.

To mimic a bit how the vanilla checkbox input element works, we'll call our attribute checked, and it will be a boolean attribute, meaning its presence or absence will represent true or false respectively.

<!-- off -->
<toggle-switch></toggle-switch>

<!-- on -->
<toggle-switch checked></toggle-switch>

Setting a property for the element's class essentially declares the attribute is important. In truth, any element can have any attribute, so by creating a property we communicate that checked is important for the toggle switch.

class ToggleSwitch extends HTMLElement {
  get checked() {
    return this.hasAttribute('checked')
  }
  set checked(value) {
    this.toggleAttribute('checked', value)
  }
}

And the interesting question: does a change in checked require a change on the element?

I can think of at least two things that should change when the checked attribute is added or removed from the toggle switch:

The switch should animate (but we'll get to that when we discuss styling)
The aria-checked attribute should reflect the checked attribute.

...what?

Recall from earlier that we are relying on the switch role for accessibility. That role requires that an accessibility attribute called aria-checked be set to either "true" or "false".

So, when checked is present, aria-checked must be "true", and when checked is absent, aria-checked must be "false".

Let's write a test for that!

it('checked attribute is updated', async () => {
  const el = await fixture(`<toggle-switch></toggle-switch>`)

  expect(el.getAttribute('aria-checked')).to.equal('false')

  el.toggleAttribute('checked', true)
  expect(el.getAttribute('aria-checked')).to.equal('true')
})

In this test, we first ensure that an unchecked toggle switch starts with an aria-checked of "false", indicating it is off to accessibility stuff. Then, we add the checked attribute and verify that aria-checked has changed to "true".

Now, to actually accomplish this in code requires using a cool feature of web components: observedAttributes and attributeChangedCallback.

observedAttributes is just a list of attributes that the element should react to if changed.
And attributeChangedCallback is the function that gets fired when any of the listed attributes change.

class ToggleSwitch extends HTMLElement {
  static get observedAttributes() {
    return ['checked']
  }

  attributeChangedCallback(name, oldValue, newValue) {
    if (name === 'checked') {
      this.setAttribute('aria-checked', this.checked.toString())
    }
  }
}

And finally, we will want to make sure the initial state is taken care of in connectedCallback:

class ToggleSwitch extends HTMLElement {
  connectedCallback() {
    this.setAttribute('aria-checked', this.checked.toString())
  }
}

Code Features:

Attributes and properties can be set on custom elements.
observedAttributes and attributeChangedCallback react to changes in attributes.

Javascript: The Filament

And now for the part of the bulb that actually glows: the filament! As the heart of the light bulb, it's fitting for the filament to represent the heart of our component, the javascript API.

What is an API?

API stands for Application Programming Interface. If you think of a car as a program, then its API would be the steering wheel, gas pedal, and brake. You cannot directly manipulate what the engine does and can only do so through those three accessible things.

As such, an API exposes ways to use an element without needing to know all of its messy guts.

Although a web component could be as simple as just coloring text, custom elements are additionally useful for bundling complex functionality into a single doodad. For example, the toggle switch component must allow someone to toggle it on and off, and so a click action must be bound to do that.

Perhaps that's not surprising, so what I find useful is to think of those potential actions as public javascript functions. Another way of putting it, if a reader is able to click the component to toggle it, then there should be a toggle() function available so that other javascript code can simulate the reader's action.

Javascript functions expose key element behaviours and actions.

For the toggle switch, when someone clicks on it, the element should go from off to on, or from on to off. As usual, we start with a test!

describe('toggling on and off', () => {
  it('via clicking', async () => {
    const el = await fixture(`<toggle-switch></toggle-switch>`)

    expect(el.checked).to.be.false

    el.click()
    expect(el.checked).to.be.true

    el.click()
    expect(el.checked).to.be.false
  })
})

Here, we are able to use the click() function to simulate someone clicking the element.

To make this test pass, all we have to do is listen for a "click" event and toggle the checked state. We will do this in connectedCallback since that's a good place to handle initialization.

class ToggleSwitch extends HTMLElement {
  connectedCallback() {
    this.addEventListener('click', () => {
      this.checked = !this.checked
    })
  }
}

Looks great, except! Remember our key point:

Key element behaviours are exposed as Javascript functions.

This means we should have a toggle() method exposing this is a key way not only readers can interact with the component, but other javascript code can too.

In fact, we'll make test for this as well!

describe('toggling on and off', () => {
  it('via the api', async () => {
    const el = await fixture(`<toggle-switch></toggle-switch>`)

    expect(el.checked).to.be.false

    el.toggle()
    expect(el.checked).to.be.true

    el.toggle()
    expect(el.checked).to.be.false
  })
})

This test is extremely similar to the previous test, with the primary difference this uses a public function (toggle()) rather than a user action (clicking).

Doing this allows two things. First, we can actually simplify the event listener from above to use our new function:

class ToggleSwitch extends HTMLElement {
  toggle = () => {
    this.checked = !this.checked
  }

  connectedCallback() {
    this.addEventListener('click', this.toggle)
  }
}

But additionally, we can now clean up the event listener with the disconnectedCallback hook!

class ToggleSwitch extends HTMLElement {
  disconnectedCallback() {
    this.removeEventListener('click', this.toggle)
  }
}

As a mirror to connectedCallback, the disconnectedCallback function is called every time the element is removed from the document. It is most useful for cleaning up listeners it may have set up elsewhere.

Code Features:

disconnectedCallback cleans up after an element when it is removed from the document.

Events: The Inert Gas

So it turns out there's a part of a light bulb you can't see but is nonetheless important for it to work: the inert gas! The bulb is filled with special air that extends the lifetime of the filament.

Continuing our Light Bulb of Web Components, the gas is represented by the event API, stuff happening under the surface but significant for other things to react to changes in our component.

An event is essentially a tidbit of code declaring that something happened, for instance "Hey, somebody toggled me on!" By emitting an event like this, listeners can react with some appropriate action.

When building a web component, we should think about what events it should emit that other elements may need to react to. In fact, this is the primary mechanism by which our <toggle-switch> element will even be useful!

Events communicate key actions or changes for other elements to react to.

In essence, our goal is for our element to be used like this:

const toggleSwitch = document.querySelector('toggle-switch')

toggleSwitch.addEventListener('toggle-switch:change', (e) => {
  // code toggling light/dark mode
})

Thinking about our <toggle-switch> component again, what are the key events we want it to emit? For the most part, there's just one: whether its state changes from off to on or vice versa.

So, whenever the checked state changes, the element should emit an event!

To write a test, we must ask three questions.

What is the event's name?
When does the event occur?
What details should be shipped with the event?

The answers to these questions will fit into this nice testing template:

import { oneEvent, fixture, expect } from '@open-wc/testing'

describe('events', () => {
  it('turned on', async () => {
    const el = await fixture(`<toggle-switch></toggle-switch>`)

    setTimeout(() => /* (2) WHEN */)
    const { detail } = await oneEvent(el, /* (1) NAME */)

    /* (3) ASSERT DETAILS */
  })
})

Answering the questions...

Name: Since our event represents a change in the state, we'll call the event "toggle-switch:change".
When: Let's emit the event any time checked is added or removed from the element.
Details: Events can carry additional information so that listeners know both what happened and anything else that may be relevant. For our one event, it's probably important to know whether the switch was toggled on or toggled off, so we'll add that to details.

If we plug these things into our testing template, we get a decent test!

import { oneEvent, fixture, expect } from '@open-wc/testing'

describe('events', () => {
  it('turned on', async () => {
    const el = await fixture(`<toggle-switch></toggle-switch>`)

    setTimeout(() => el.checked = true)
    const { detail } = await oneEvent(el, 'toggle-switch:change')

    expect(detail.checked).to.be.true
  })
})

The two important functions in this test are setTimeout (provided by Javascript) and oneEvent (provided by open-wc).

oneEvent just waits for one event to occur, and times out with a failure if the event never occurs.
setTimeout adds our toggle to a list of things for Javascript to do eventually. It's needed because if we didn't use it, our event could potentially fire before we even started listening for it!

Ok, let's actually emit the event now!

Since our event is custom to our new element, we will dispatch a Custom Event, and since we want to do it any time checked changes, we'll perform the dispatch with the code that reacts to when that attribute changes.

class ToggleSwitch extends HTMLElement {
  attributeChangedCallback(name, oldValue, newValue) {
    if (name === 'checked') {
      this.setAttribute('aria-checked', this.checked.toString())
      this.dispatchEvent(new CustomEvent('toggle-switch:change', {
        detail: {
          checked: this.checked
        }
      }))
    }
  }
}

Code Features:

oneEvent tests that an event has occurred.
Custom Events let you dispatch events specific to your component.

Styling: The Globe

So, we've done all this coding so far, but we can't actually see the switch yet... Let's finally put the globe on our light bulb by adding some styling to our element!

To be honest, styling web components is entirely deserving of its own article, made both interesting and complicated by a tiny thing called the Shadow DOM. MDN covers using the shadow dom in good detail, so for the purposes of this article we'll talk about it just enough to style the <toggle-switch>.

Shadow DOM allows web components to, in essence, carry around their own personal document hidden from the primary web page document. It's kind of like... flowers.

Photo by bardia Hashemirad on Unsplash

As a gardener, you can't tell a flower what shape to take or how many petals to have, as that's determined by its own DNA. You can determine how many flowers are in your garden, and maybe you can influence some of the flower's colors by feeding it colored water, but beyond that you don't get much say.

Similarly, an element's shadow dom (flower) is encapsulated from the rest of the document, meaning the document (gardener) cannot directly influence elements defined in the shadow dom; neither can different web components clash with each other.

This turns out to be rather important for <toggle-switch> because we now have competing concerns:

We must use the shadow dom to give our element a decent default "switch look"
But we also want developers to customize it from outside the component to fit their website's look and feel

These competing concerns are incredibly common, and therefore the shadow dom is actually not completely impenetrable. Although the parent document can never arbitrarily customize stuff in the shadow dom, there are a few exceptions:

CSS variables can take on values from beyond the shadow dom.
Elements within the shadow dom can be assigned shadow part names which can be directly selected with CSS.

These exceptions form a web component's Styling API, specifically defined opportunities for customization. And just like how we have to intentionally decide what attributes, javascript functions, and events to expose, we also have to choose what CSS variables or parts can be styled.

Styling is made available through carefully chosen CSS variables and shadow parts.

Earlier I said we "must" use the shadow dom. Why?

In our case, we want to maintain the internal structure of the element, which means it shouldn't be exposed to the outside. Deciding what goes in shadow dom or not is important for creating an element's style API, but is complex enough to merit its own article.

This stack overflow post helped me understand this concept and links to other useful resources.

At long last, let's style this web component!

To make the switch easy to customize, we are going to minimally style it. Our base switch is gonna be just a square that moves back and forth along a track like this:

First, we must attach a shadow root to the element and create a basic template for our element.

const template = document.createElement('template')
template.innerHTML = `
  <style>
    /* CSS HERE */
  </style>
  <span part="track">
    <span part="slider"></span>
  </span>
`

class ToggleSwitch extends HTMLElement {
  constructor() {
    super()

    this
      .attachShadow({ mode: 'open' })
      .appendChild(template.content.cloneNode(true))
  }
}

Of note, we want developers using this toggle switch to be able to customize both the sliding bit and the track underneath it, so to make that possible we are assigning shadow parts to each element. This will make it possible for users to style those specific components like this:

toggle-switch::part(slider) {
  border-radius: 1em;
}

With the basic template structure done, all that's left is adding CSS! All CSS added will go into the style tag in the template above.

First, let's give the element some basic sizing.

:host {
  display: inline-block;
  width: 2em;
  height: 1em;
  cursor: pointer;
}

span {
  box-sizing: border-box;
  display: inline-block;
  line-height: 1;
}

Two things of interest here:

The :host selector is special in the context of shadow dom. It basically means "style the thing that contains the shadow dom", which is the web component itself. In our case, this styles the toggle-switch tag.
The span only selects spans within the shadow dom of the element. It does not globally style all spans on the page! That's part of the power of encapsulation.

Next, we'll style the track and slider to look like our squareish examples:

[part="track"] {
  width: 100%;
  height: 100%;
  background-color: #dddddd;
  text-align: left;
}

[part="slider"] {
  width: 50%;
  height: 100%;
  background-color: #777777;
  vertical-align: text-top;
}

And for the last part, we need to style what the component looks like when it has been checked. Recall that the checked attribute on the <toggle-switch> tag determines its on/off state. This can be selected for with an attribute selector using :host!

[part="track"], [part="slider"] {
  transition: all 256ms;
}

:host([checked]) [part="slider"] {
  transform: translateX(100%);
}

Code Features:

Shadow DOM encapsulates structure, style, and behaviour from the overall document.
Shadow Parts allow outside CSS to customize specific inner elements of a web component.
:host lets you style the web component itself from its shadow dom.

We Invented a Light Bulb!

And with that, we just covered the six key aspects to building great web components! And in the process we built both a light bulb and a toggle switch!

Web Components create new semantics through custom elements.
Accessible components allow for multiple methods of interaction.
Attributes surface important state, configuration, and nuanced meaning.
Javascript functions expose key element behaviours and actions.
Events communicate key actions or changes for other elements to react to.
Styling is made available through carefully chosen CSS variables and shadow parts.

But... is it truly complete?

Almost! There are a few things I skipped over to simplify the tutorial:

Accessibility: How do we label the switch? Can we integrate this with the HTML label element?
Javascript: When someone tabs to the toggle, can they activate it by pressing Enter or Space?
Attributes: Can a toggle switch be disabled like other HTML input controls?

Feel free to try to tackle these issues yourself! Or, see how it all works in my implementation of the <toggle-switch> element on Github.

Auroratide / toggle-switch

Full Code

const template = document.createElement('template')
template.innerHTML = `
  <style>
    :host {
      display: inline-block;
      width: 2em;
      height: 1em;
      cursor: pointer;
    }

    span {
      box-sizing: border-box;
      display: inline-block;
      line-height: 1;
    }

    [part="track"] {
      width: 100%;
      height: 100%;
      background-color: #dddddd;
      text-align: left;
    }

    [part="slider"] {
      width: 50%;
      height: 100%;
      background-color: #777777;
      vertical-align: text-top;
    }

    [part="track"], [part="slider"] {
      transition: all 256ms;
    }

    :host([checked]) [part="slider"] {
      transform: translateX(100%);
    }
  </style>

  <span part="track">
    <span part="slider"></span>
  </span>
`

export class ToggleSwitch extends HTMLElement {
  static elementName = 'toggle-switch'

  static get observedAttributes() {
    return ['checked']
  }

  constructor() {
    super()

    this
      .attachShadow({ mode: 'open' })
      .appendChild(template.content.cloneNode(true))
  }

  connectedCallback() {
    this.setAttribute('role', 'switch')
    this.setAttribute('tabindex', '0')
    this.addEventListener('click', this.toggle)
  }

  disconnectedCallback() {
    this.removeEventListener('click', this.toggle)
  }

  attributeChangedCallback(name, oldValue, newValue) {
    if (name === 'checked') {
      this.setAttribute('aria-checked', this.checked.toString())
      this.dispatchEvent(new CustomEvent('toggle-switch:change', {
        detail: {
          checked: this.checked
        }
      }))
    }
  }

  get checked() {
    return this.hasAttribute('checked')
  }
  set checked(value) {
    this.toggleAttribute('checked', value)
  }

  toggle = () => {
    this.checked = !this.checked
  }
}

window.customElements.define(ToggleSwitch.elementName, ToggleSwitch)

import { fixture, expect } from '@open-wc/testing'

describe('toggle-switch', () => {
  describe('accessibility', () => {
    it('default role', async () => {
      const el = await fixture(`<toggle-switch></toggle-switch>`)

      expect(el.getAttribute('role')).to.equal('switch')
    })

    it('tabbing', async () => {
      const el = await fixture(`<toggle-switch></toggle-switch>`)

      expect(el.getAttribute('tabindex')).to.equal('0')
    })
  })

  describe('attributes', () => {
    it('checked attribute is updated', async () => {
      const el = await fixture(`<toggle-switch></toggle-switch>`)

      expect(el.getAttribute('aria-checked')).to.equal('false')

      el.toggleAttribute('checked', true)
      expect(el.getAttribute('aria-checked')).to.equal('true')
    })
  })

  describe('toggling on and off', () => {
    it('via clicking', async () => {
      const el = await fixture(`<toggle-switch></toggle-switch>`)

      expect(el.checked).to.be.false

      el.click()
      expect(el.checked).to.be.true

      el.click()
      expect(el.checked).to.be.false
    })

    it('via the api', async () => {
      const el = await fixture(`<toggle-switch></toggle-switch>`)

      expect(el.checked).to.be.false

      el.toggle()
      expect(el.checked).to.be.true

      el.toggle()
      expect(el.checked).to.be.false
    })
  })

  describe('events', () => {
    it('turned on', async () => {
      const el = await fixture(`<toggle-switch></toggle-switch>`)

      setTimeout(() => el.checked = true)
      const { detail } = await oneEvent(el, 'toggle-switch:change')

      expect(detail.checked).to.be.true
    })
  })
})

Constructing web components like a pro.
@open-wc/testing provides useful testing helpers for putting our component on a web page.
@web/test-runner runs our tests in a real browser.
Test Fixtures set up an element on a page for testing.
connectedCallback initializes an element when inserted onto the page.
Attributes and properties can be set on custom elements.
observedAttributes and attributeChangedCallback react to changes in attributes.
disconnectedCallback cleans up after an element when it is removed from the document.
oneEvent tests that an event has occurred.
Custom Events let you dispatch events specific to your component.
Shadow DOM encapsulates structure, style, and behaviour from the overall document.
Shadow Parts allow outside CSS to customize specific inner elements of a web component.
:host lets you style the web component itself from its shadow dom.

A Typewriter, but using a New HTML Tag

Timothy Foster — Thu, 09 Sep 2021 19:55:08 +0000

So last time, I made a typewriter animation without HTML, CSS, nor Javascript. What happens if instead of using nothing, we allow ourselves to use... everything?

All this is achieved with a fancy new HTML tag, <typewritten-text>!

This is a <typewritten-text><strong>typewriter effect!</strong></typewritten-text>

Find out how to install and use it here:

Auroratide / typewritten-text

The text types itself out!

A New HTML Tag?

The HTML standard allows developers to define custom elements through Web Components. Making a new element just requires a handful of Javascript, from there letting you define as much or as little functionality as needed.

class MyElement extends HTMLElement {
  // code for how the element looks and behaves
}

window.customElements.define('my-element', MyElement)

The typewritten-text element is one such web component, designed to provide a semantic, flexible, and reusable typewriter component!

Since web components are native browser technology, they are meant to work with most of our beloved frameworks out of the box (looking at you, React...). That's one of my favorite things about them!

Granted, the developer experience can be... painful sometimes. This innocent little element turned out to be much much harder than I originally thought in order to achieve all my goals for it.

The `typewritten-text` Element

Once Javascript enters the arena, basically anything becomes possible.

No need for monospace requirements! The inner text can be of any font or size; in fact, it can mix fonts if you want.
Built-in multiline support, for if you want to type out a longer sentence or two.
A very simple interface; you can basically use it like any standard HTML tag.

And of course, I put in the effort to make it as accessible as possible.

It represents its textual content regardless of current typed state, especially useful for those using Assistive Technologies.
The blinking cursor animation is disabled for people who prefer reduced motion.
No content-shifting either! The element's size is always the size of its content.

Perhaps the most interesting feature is its events. The element dispatches events when characters are typed or the phrase is finished. By listening to those events, you can use the magic of code to make the typewriter do any custom behaviour that's desired!

For example, starting another typewritten text:

first.addEventListener('typewritten-text:phrasetyped', () => {
    second.start()
})

Showcasing

Here's a couple of nifty things you can do with the typewritten-text component!

Typewriter Cycle

Using events, it's simple to cycle through different texts to type out.

The typewritten-text element is designed to be very basic so it can be used in as many ways as possible, which is why the cycle effect is not built-in. A different web component could be made to encapsulate the effect, though!

Character Dialog

Characters tend to talk with a typewriter animation also!

Hit Rerun at the bottom of the frame to see the animation again.

Find out more

All information on how to install and use the typewritten-text component can be found on github!

Auroratide / typewritten-text

The text types itself out!

I may soon write a little more about the process of actually making (and testing) a web component.

A Typewriter, but with no HTML, CSS, or JS?!

Timothy Foster — Sun, 29 Aug 2021 19:49:21 +0000

Apparently a battle of sorts has erupted amongst devs clamoring for the title of Best Typewriter Animator Person.

@alvaromontoro started with a Typewriter effect in CSS
@afif then gave us A scalable CSS only Typewriter Effect
@inhuofficial has promised us an HTML-only typewriter
And @alvaromontoro came back with an Animated no-element typewriter

In the classic spirit of one-uppery that has arisen, it was only a matter of time before someone, somewhere took on the most legendary of tasks: to create a typewriter animation for the web without using anything. No Javascript. No CSS. Not even HTML.

Behold, the power of Scalable Vector Graphics.

Ok but actually don't use this if you want a typewriter animation! It's got browser compatibility and accessibility issues, but at least it's a cute experiment.

How it works

The SVG spec has something called Synchronized Multimedia Integration Language (SMIL) which allows animations to be defined in the XML document directly.

For example, consider the animate tag. When made a child of some shape like rect, you can choose what attribute to animate over time and specify the way in which it changes.

So for example, the text cursor is given a simple blink animation just by adjusting the width of a rectangle between 0 and 1, and doing it discretely so it blinks:

<rect fill="black" x="0" y="4" width="1" height="12">
  <animate
    attributeName="width"
    calcMode="discrete"
    values="1; 0"
    dur="1s"
    repeatCount="indefinite" />
</rect>

This is the first time I've ever used SMIL, so almost certainly someone smarter than me can find a better way than adjusting an overlaying white rectangle!

Tips That Made My Site More Accessible

Timothy Foster — Sat, 28 Aug 2021 21:47:02 +0000

If you want to learn more about creating accessible content, I highly recommend giving this article by @inhuofficial a read:

Article No Longer Available

What is accessibility? Accessibility is a way of making things usable by as many people as possible, regardless of ability or disability. I like to call it "universal design".

The article may look daunting at first, and indeed it took me some hours over the course of a few days to read through and digest everything, but it's worth every minute!

I like this article for taking the enormity of accessibility and condensing it into quick wins applicable to a many different cases. It's a great entry point, providing a list of topics into which you can dig deeper over time.

Although I had already been making accessibility improvements to my website, I was still able to find some valuable action items for myself. Here are the top five ways I was able to improve my website!

Tip 12: One h1 per page

The principle is simple: each page should have one and only one <h1> heading!

Of the many pages on your site, the <h1> heading tells your visitors exactly where they are.
Assistive technology such as screen readers rely on this heading to announce that location.
And usually, this heading demarks the start of the main content, after all the navigation at the top.

A screen reader is capable of reading the content of a site out loud to those who either can't or would rather not read the text. As a feature, they allow people to look at all the headings on a page to jump to where they want to go.

The headings menu for Mac's VoiceOver tool

Well, each of the pages on my site use to have two level one headings: one was the page title, but the other was the website's title, "Auroratide". And that website title was the same on every single page. That would be pretty annoying to someone using a screen reader!

The change? Instead of using an <h1>, the site's title no longer uses a heading at all and is simply styled to look like one.

<a class="page-title" href="/">Auroratide</a>

Tip 29: alt attributes

Images are fantastic, but not everyone can see them. Therefore, it is important each image has a suitable text replacement which can either be shown to someone or read aloud by a screen reader. This is called an image's alt attribute.

Before finding this article, I had already audited every single image on my website to give them suitable text alternatives, but this point is so important I decided to bring it up anyway.

To write good alt text, imagine you are sharing an article with someone over the phone and need to describe the image to them with words. What you say is generally good alt text! For more on that, here's an article I had recently written:

Image Alt Text, the Way the Spec Intended It

Timothy Foster ・ Jul 16 '21

#html #a11y #webdev

Tip 43: Include a skip link to bypass site navigation

Some people prefer to navigate a website entirely with a keyboard, pressing Tab to go from landmark to landmark.

Usually, pressing Tab on a page for the first time takes you to the very first link, which might be the site's title.

After the site's title are the navigation links.

And after that is the actual page's content.

Now imagine hopping from page to page on a site, and every single time a new page is loaded you have to Tab through the entire navigation just to get to the content. Hence the skip link!

A skip link allows someone to bypass the navigation and get directly to the content. As such, it is generally the first focusable item.

A basic implementation links to a main element in the document, hiding the link off-screen until it becomes focused:

<a class="skip-link" href="#main">Skip to Content</a>
<main id="main"></main>
<style>
    .skip-link {
        position: absolute;
        left: -9999px;
    }

    .skip-link:focus {
        top: 0;
        left: 0;
    }
</style>

Here is my implementation of skip link on Github.

Tip 52: Font Size

I remember the early 2000s where websites had tiny Times New Roman fonts. At the time I was also tiny and could read those fonts; nowadays, any time I encounter one of these relics of the past (almost always some .edu site), I struggle severely!

Today, the standard minimum font size is 16px.

Before reading the accessibility tips, my website had a base font size of 18px, which is actually bigger than the minimum. However, I often make use of side text, stuff tangential to the main content but I feel is worth including. This side text uses a smaller font, which dipped it into a range smaller than 16px. Yikes!

As a result, I universally bumped all font sizes up so that now the smallest font possible is 16px, and the usual font is 20px. In fact, the universal increase was necessary since I like the aesthetic of a thin font, but using a thin font raises the size threshold in order to remain accessible.

The code change for this was not very bad since I make liberal use of CSS variables. Here is a full diff of the font change for those interested.

Tip 85: Don't forget the :visited state

You've probably seen this before if you've used the Google search engine: links you have been to are a different color from those that are new.

Don't ask why I was researching multiple time dimensions

Turns out I rely on this feature (more than I care to admit) to re-find pages I should have bookmarked! From an accessibility standpoint, differentiating visited links is especially important for those with memory impairment. And thankfully, all it takes is a couple lines of CSS!

a:visited {
    color: var(--skin-text-visited);
}

Prior, I had deliberately made all my links the same out of aesthetic preference. However, learning how this simple change could benefit a lot of people convinced me to apply the difference, and honestly I quite like it now.

Bonus Tip 101: People are not users

And finally, my favorite tip: Do not call people "users"!

At least for me, I get very different mental images when I think of users versus people. It's the difference between thinking of the website, or thinking of the face behind the website. I develop far more empathy for the latter, and ultimately empathy is at the core of accessibility.

The Other 95 Tips

This was just a list of five improvements I was able to make to my website from a list of 101 tips. I highly encourage you to bookmark @inhuofficial 's article to reference when needed!