I recently shipped some updates to my blog. Through the design/development process, I had some insights which made me question my knee-jerk reaction to building pieces of a page as JS-powered interactions on top of the existing document.

With cross-document view transitions getting broader and broader support, I’m realizing that building in-page, progressively-enhanced interactions is more work than simply building two HTML pages and linking them.

I’m calling this approach “lots of little HTML pages” in my head. As I find myself trying to build progressively-enhanced features with JavaScript — like a fly-out navigation menu, or an on-page search, or filtering content — I stop and ask myself: “Can I build this as a separate HTML page triggered by a link, rather than JavaScript-injected content built from a button?”

I kinda love the results. I build separate, small HTML pages for each “interaction” I want, then I let CSS transitions take over and I get something that feels better than its JS counterpart for way less work.

Allow me two quick examples.

Example 1: Filtering

Working on my homepage, I found myself wanting a list of posts filtered by some kind of criteria, like:

• The most recent posts
• The ones being trafficked the most
• The ones that’ve had lots of Hacker News traffic in the past

My first impulse was to have a list of posts you can filter with JavaScript.

But the more I built it, the more complicated it got. Each “list” of posts needed a slightly different set of data. And each one had a different sort order. What I thought was going to be “stick a bunch of <li>s in the DOM, and show hide some based on the current filter” turned into lots of data-x attributes, per-list sorting logic, etc. I realized quickly this wasn’t a trivial, progressively-enhanced feature. I didn’t want to write a bunch of client-side JavaScript for what would take me seconds to write on “the server” (my static site generator).

Then I thought: Why don’t I just do this with my static site generator? Each filter can be its own, separate HTML page, and with CSS view transitions I’ll get a nice transition effect for free!

Minutes later I had it all working — mostly, I had to learn a few small things about aspect ratio in transitions — plus I had fancy transitions between “tabs” for free!

This really feels like a game-changer for simple sites. If you can keep your site simple, it’s easier to build traditional, JavaScript-powered on-page interactions as small, linked HTML pages.

Example 2: Navigation

This got me thinking: maybe I should do the same thing for my navigation?

Usually I think “Ok, so I’ll have a hamburger icon with a bunch of navigational elements in it, and when it’s clicked you gotta reveal it, etc." And I thought, “What if it’s just a new HTML page?”^[1]

Because I’m using a static site generator, it’s really easy to create a new HTML page. A few minutes later and I had it. No client-side JS required. You navigate to the “Menu” and you get a page of options, with an “x” to simulate closing the menu and going back to where you were.

I liked it so much for my navigation, I did the same thing with search. Clicking the icon doesn’t use JavaScript to inject new markup and animate things on screen. Nope. It’s just a link to a new page with CSS supporting a cross-document view transition.

Granted, there are some trade-offs to this approach. But on the whole, I really like it. It was so easy to build and I know it’s going to be incredibly easy to maintain!

I think this is a good example of leveraging the grain of the web. It’s really easy to build a simple website when you can shift your perspective to viewing on-page interactivity as simple HTML page navigations powered by cross document CSS transitions (rather than doing all of that as client-side JS).

1. Jason Bradberry has a neat article that’s tangential to this idea over at Piccalil. It’s more from the design standpoint, but functionally it could work pretty much the same as this: your “menu” or “navigation” is its own page. ⏎

Reply via: Email · Mastodon · Bluesky

But how do you choose which service to use?

Most folks default to Google Maps, which is a very powerful platform, but also comes with probably way more than you need, and has a cost involved at a certain level. What if there were a simpler, smaller, and dare I say, free and open source alternative? Leaflet.js is exactly that.

Leaflet is incredibly simple and flexible. It lets you quickly add interactive maps to your web pages with little overhead.

Before we jump into code, let’s consider a simple, but realistic example. You run a website that helps prospective cat owners find cats that need a new home. Your data comes from an API (which for our sake will be a JSON file) and includes information like:

• Characterstics of the cat
• How to contact the current owner
• Where the cat could be picked up, a location in latitude and longitude.

What we want to do here is see how much effort is required to add this to a web page. Let’s get started!

Including the Leaflet Library

We’ll start with a simple bit of HTML. I’m using CodePen for the samples so this will be a subset of the entire page of course. First, just some introductory content and a place for our map.

<h2>Cat Connector</h2>

<p>
  Use the map below to help find cats who need a new home. 
  Every cat deserves a loving home!
</p>

<div id="map"></div>

The map will need a size of some sort, so I used the following CSS:

#map {
  width: 100%;
  height: 500px;
}

If you follow the Leaflet Quick Start, you can see two dependencies that need adding, first, a CSS resource:

<link 
  rel="stylesheet" 
  href="https://unpkg.com/leaflet@1.9.4/dist/leaflet.css"
  integrity="sha256-p4NxAoJBhIIN+hmNHrzRCf9tD/miZyoHS5obTRR9BMY="
  crossorigin=""
/>

And then the library itself:

<script 
  src="https://unpkg.com/leaflet@1.9.4/dist/leaflet.js"
  integrity="sha256-20nQCchB9co0qIjJZRGuk2/Z9VM+kNiyxNV1lvTlZBo="
  crossorigin="">
</script>

For CodePen, these was done in the Pen Settings in the External Stylesheets and External Scripts sections.

Now, we need to actually add the map, and here’s where you need to think a bit. In order to create a map, you’ll need a location to begin with. What this location is depends on a lot of factors. If I were rendering maps in the continental United States, I could center it on America. If I were mapping castles in Germany, obviously I’d pick a location somewhere in the country.

Another factor you have to consider is the initial zoom. How close, or how far, the map initially shows itself will also depend on the kind of data you’re rendering.

For our pretend cat rehoming website, we’ll assume Lafayette, Louisiana, which just so happens to be where I live. The latitude of Lafayette is 30.216667 and the longitude is -92.033333.

This can be done with one line:

let map = L.map('map').setView([30.216667, -92.033333], 12);

If you were to run this right now, you would see:

Where’s the map? The final part you need is a tile provider. Map tiles are the parts that make up any interactive map. As you go to different locations, and different zoom levels, the map is rendered from a set of tiles, based on those factors (location and zoom). OpenStreetMap provides free map tiles (with attribution!) and can be added to Leaflet like so:

L.tileLayer('https://tile.openstreetmap.org/{z}/{x}/{y}.png', {
  maxZoom: 19,
  attribution: '&copy; <a href="http://www.openstreetmap.org/copyright">OpenStreetMap</a>'
}).addTo(map);

Let’s take a look at what we have so far:

We haven’t actually added any data yet and it’s possible we may need to tweak multiple things. Maybe the map needs to be bigger? Maybe our centered location isn’t quite right? Our default zoom may not be optimal either. These are all things that will come into play as we start adding data — so let’s do that next!

Our Data

Before we get into how Leaflet can show data, let’s look at our sample data. Our cats will be returned as static data, an array of results. Here’s a portion of the data:

let availableCats = [
  {
    cat: {
      name: "Fluffy",
      age: 5,
      gender: "male",
      breed: "calico"
    },
    owner: {
      name: "Raymond Camden",
      contactEmail: "raymondcamden@gmail.com",
      contactPhone: "555-555-5555"
    },
    location: {
      latitude: 30.227394,
      longitude: -92.02909
    }
  },
  {
    cat: {
      name: "Pig",
      age: 12,
      gender: "female",
      breed: "calico"
    },
    owner: {
      name: "Lindy Camden",
      contactEmail: "lindyjcamden@gmail.com",
      contactPhone: "555-555-5555"
    },
    location: {
      latitude: 30.231695,
      longitude: -92.007103
    }
  }
];

To emulate an API call, we can wrap this up in a function like so:

async function getAvailableCats() {
  return [
    // list of cats here...
  ]
}

And then update our code to let us call this asynchronously:

document.addEventListener("DOMContentLoaded", init, false);
async function init() {
  let cats = await getAvailableCats();

  let map = L.map("map").setView([30.216667, -92.033333], 12);

  L.tileLayer("https://tile.openstreetmap.org/{z}/{x}/{y}.png", {
    maxZoom: 19,
    attribution:
      '&copy; <a href="http://www.openstreetmap.org/copyright">OpenStreetMap</a>'
  }).addTo(map);
}

At this point, we’ve got data, but how to add it to the map? Leaflet lets you ‘draw’ on a map in many different ways, but the simplest is by adding a marker:

let marker = L.marker([latitude, longitude]).addTo(map);

Since we got the cats earlier in the function, we just need to loop over them:

cats.forEach(c => {
  let marker = L.marker([c.location.latitude, c.location.longitude]).addTo(map);
});

You can see this version below:

Notice that it’s possible that changing the zoom may help here, there’s a lot of space around the data and we could get clodser in. However, maybe we know our organization could, at any time, get more data farther out. This is exactly what I was talking about in terms of understanding your data, both what’s immediately available and what may come later.

Leaflet also supports the idea of taking a set of locations and ensuring they all ‘fit’ by default. That’s just one example of how powerful the API is, but we’ll keep it simple for now.

Adding Interactivity

Now for the last part of the puzzle. In order for the information on the map to actually be useful, we need to associate the data for those markers and provide some form of UI to share that with the users. In it’s simplest form, Leaflet lets you bind popups to markers in, literally, one simple method call.

You take this:

let marker = L.marker([latitude, longitude]).addTo(map);

And add:

let marker = L.marker([latitude, longitude]).addTo(map).bindPopup('Set some HTML or just regular text here.');

That’s it! So given our loop over the cat data, here’s a new version with that. I created a template string to more nicely format the information:

cats.forEach(c => {
  let desc = `
    <h3>${c.cat.name}</h3>
    <p>
      ${c.cat.name} is a ${c.cat.gender} ${c.cat.breed}.
    </p>
    <p>
      Owner: ${c.owner.name}<br>
      Email: ${c.owner.contactEmail}<br>
      Tel: ${c.owner.contactPhone}<br>
    </p>
  `;
  L.marker([c.location.latitude, c.location.longitude]).addTo(map).bindPopup(desc);
});

This one method handles the click interaction, creating the popup, even automatically closing another popup if you forget to close one. Here’s the complete demo:

What Else?

This introduction only scratches the surface of what’s possible and you should peruse the docs for a full idea. Leaflet is great, and free, but, you should also be aware of some of the things you don’t get that you would with Google Maps or HERE. These include the various ‘services’, like

• Routing
• Traffic information
• Geocoding (and Reverse Geocoding)

This doesn’t mean you can’t make use of those services along with Leaflet. I discussed an example of this late last year: “Using Geocoding with Leaflet”. That being said, keep this in mind when planning your projects as it may impact your decision on whether or not to use the library.

• Good forms work without client JavaScript (Brian LeRoux)
• Good forms always submit (Brian LeRoux)
• Good forms remember values and display problems inline (Brian LeRoux)
• Good login forms work with password managers (Mingo Hogan)
• Good forms use a <form> tag
• Good forms use appropriate input types
• Good forms have clear labelled inputs and buttons
• Good forms have focus states
• Good forms have logical tab order
• Good forms allow paste
• Good form elements leverage the inputmode attribute
• Good form elements leverage the autocomplete attribute
• Good search forms wrap the <form> tag in a <search> element
• Good forms can be reset with a <button type=reset>
• Good forms participate in formData
• Good forms don’t use placeholder as a label
• Good forms work on phones
• Good forms don’t popup and ask for personal information
• Good forms only ask for what is necessary and aren’t too long
• Good forms use HTTPS
• Good forms use the proper HTTP verbs
• Good forms validate on the client AND on the server
• Good forms have been driven with a screen reader before going to production
• Good forms clearly denote required attributes
• Good forms warn about costly or destructive actions
• Good forms make the baby Jesus smile
• Good authenticated forms should have a server-generated nonce value
• Good forms should do a pre-flight check for navigator.onLine before attempting a submit
• Good forms start with accent-color for styling and only get more complex if necessary
• Good forms see custom controls as a radioactive asset that must be removed at the earliest opportunity

Anyways. People should talk about forms more. Here’s some more resources on good form design.

• Form Design Patterns by Adam Silver
• Web Form Design by Luke Wroblewski
• Form Design Mastery by Adam Silver
• Better Onboarding by Krystal Higgins

I had been aware of the scripting CSS media feature but I was still under the impression that cross-browser support was lacking. What a pleasant surprise to discover that it has been available in all modern browsers as of December 2023 according to caniuse.com. With this feature, we can provide alternative CSS rules depending on whether or not JavaScript is available in the user's browser. It can also help reduce flashes of unstyled content or undesirable layout shifts.

Usage

We can progressively enhance our styles:

@media (scripting: enabled)
 
{
 
.my-element 
{
 
}
}

Or we can gracefully fall back to some alternate styles:

@media (scripting: none)
 
{
 
.my-element 
{
 
}
}

There's also an initial-only value, which is for scripting that is enabled during page load but not after. The Media Queries Level 5 W3C Working Draft includes a couple cases where it can be useful.

Examples are printed pages, or pre-rendering network proxies that render a page on a server and send a nearly-static version of the page to the user.

I don't personally imagine using initial-only much, if ever. Although, I'd be interested to find more specific examples of it in practice.

The time before the query

Before this feature, one approach for detecting JavaScript support was by setting a custom selector on the opening html tag—a common one seen in the wild is the no-js class name. If JavaScript is supported and enabled, it removes that selector just prior to rendering page content. When JavaScript is disabled, we can supply alternative styles that adapt to the experience.

<html class="no-js">
 
</html>

.no-js .my-element 
{
 
}

Is this real life?

Imagine a new web campaign is on the cusp of going live and it's time to connect with all the key stakeholders. Everything looks great, most of the team satisfied with the result, but then suddenly some hip marketer in the meeting emphatically requests a complex intro animation on the hero component when the page loads. They gesture wildly as they ask for the main headline to fade in, shrink away as if it were being pulled back on a sling shot, and then... at this point they make an explosion noise with their mouth. "Make it pop!" they decree a mere 24 hours before launch.

Woof. Better get started.

To handle the complexity of this work, we might reach for an animation library such as GSAP. But what does the user see when JavaScript is not available, not to mention if a user's prefers reduced motion setting is enabled? We'll need to consider an alternate version of the hero without all that swooping and scaling.

This media query unlocks the ability to provide CSS rules that are a better fit to the user's experience. In the CodePen demo below, if we disable JavaScript, we'll find that the animation is skipped and the static headline is displayed.

Open CodePen demo

Watch that flash

To really make the intro animation feel smooth on page load, the demo relies on the scripting media query to hide the headline with CSS. By doing so, we won't catch a flash of unstyled text before the GSAP animation is loaded. Also, we only want to hide the headline if JavaScript is available, otherwise it would be hidden for users when it's disabled.

In the following video, watch what happens when the headline is not hidden on page load. The text flashing is even more glaring when throttling on a slower network.

Combining queries

In the CSS tab of the demo, notice that the media queries are combined to check both scripting and reduced-motion conditions.

@media (scripting: enabled) and (prefers-reduced-motion: no-preference)
 
{
 
}
 
@media (scripting: none), (prefers-reduced-motion)
 
{
 
}

Each condition can surely have exclusive styles if the desired outcome calls for it, but it's nice that we can combine them where there's overlap in rulesets.

Helpful resources

Back to all blog posts

If you take nothing else away from this post, I want you to remember this: Write alternative text as if you’re describing the image to a friend.

I find people often get too wrapped up in what the “rules” are for alternative text. Sure, there are lots of things to be aware of, but almost all of them are covered under this simple guideline. If you were talking to a friend on the phone* and wanted to describe a meme you saw, you might say “There was this dog wearing safety glasses, surrounded by chemistry equipment, saying ‘I have no idea what I’m doing.’”

Keep it brief, but informative! Give the most important information and leave out unimportant details.

*I know, I know, no one actually talks on the phone anymore. If the very idea is stressing you out, you can replace “describing a meme over the phone” with “describing a meme to your getaway driver as you flee the scene of your latest heist, pursued by the detective that’s been hot on your heels since the job in Naples, so she’s understandably stressed and doesn’t want to look at a funny dog picture on your phone while she’s driving.”

Context matters

Of course, context informs your description. If I was describing the chemistry dog meme to a chemistry major, I might want to emphasize all the things the dog is doing wrong. If I was describing it to someone who works in a hazardous spill response team, I might mention that the dog is pouring one of the mystery fluids into a coffee mug. As an example, let’s consider this image from a Batman movie.

A fan-run Batman wiki, where the audience is likely familiar with the characters, might use this as alternative text:

Commissioner Gordon, wearing his signature trenchcoat, stands near the batsignal, considering whether to light it, alerting Batman.

In contrast, an article about cinematography, where the author chose this image as an example of a framing technique and Batman isn’t the primary focus, might highlight other features of the image.

In this shot, director Christopher Nolan has framed Commissioner Gordon, played by Gary Oldman, pensively looking away from the unlit batsignal towards the sky, with the city visible behind him, reminding the viewer of the stakes inherent in his decision to summon Batman.

And if Batman had a social media account, he might take a slightly different approach.

Gordon looking goofy AF after I dipped out while he was talking again LOL

All of these are valid alternative text choices for audiences in certain contexts.

You don’t need to say it’s an image

Most screenreaders will say “image” or “graphic” before reading the alternative text, so starting with “Image of X” is redundant. The only time you need to mention the image itself is if the medium matters, such as artwork and diagrams. For example, “a charcoal sketch of a cute kitten,” “the blueprints for the mansion we’re going to rob,” or “A chart showing a 50% decline in sales over three years.”

But you should include punctuation

Eric Bailey reminds us to add punctuation to our alternative text. If your alternative is only a single sentence, it might feel strange to include punctuation. But remember that it won’t be read in isolation, it will be read along with the surrounding text. Ending your sentence with a proper period or other punctuation will communicate to the screen reader how to transition from the alternative text to the following text.

Should alternative text describe race?

Sometimes! Like everything, it’s contextual. I highly recommend reading “The case for describing race in alternative text attributes” by Tolu Adegbite, and “Thoughts on skin tone and text descriptions” by Léonie Watson. They both point out that by not mentioning race, we may be unintentionally reinforcing the idea that the unspoken default is white.

Think of it the same way we encourage the adoption of gender pronouns in profiles even for cisgender people. It’s not about whether anyone might be confused about what your pronouns are. It’s about normalizing the idea that everyone has pronouns and they may not match your expectations.

Decorative images don’t need alternative text, but your image probably isn’t decorative.

It’s true that purely decorative images are allowed to use an empty string for their alt attribute. However, as Eric Bailey points out, your image is probably not decorative. In a nutshell, the term “decorative” means the image does not visually communicate information, not that it is used as decoration.

A spacer GIF is decorative. Image borders are decorative. A button that only contains an icon image is not decorative. This photo of the safe that we’ll be cracking in the mansion is not decorative. A company’s logo is not decorative.

What about a person’s avatar, displayed next to their name?

This is a tricky case. If you have a person’s photo displayed right next to their name, and the alternative text only contains their name, then the screen reader will hear the person’s name twice, which adds no value. For example, at the top of this page, you can see my avatar next to my name. We’ve opted to leave the alt attribute empty on the avatar, because we don’t want screen reader users to hear “Image, Scott Vandehey, Link, Scott Vandehey.”

But… it’s not quite that simple. It depends on what the image shows. In “Writing great alt text: Emotion matters,” Jake Archibald makes the case that an avatar photo of himself on a conference site that showed him hiding behind a plant actually contained information that should be expressed in the alternative text, and opted for “Jake Archibald hiding behind a plant.”

As usual, context matters, and when in doubt, try reaching out to real users of assistive technology for opinions.

Conclusion

I know I started out by saying you only need to remember one guideline, and then gave you, like, seven. But I stand by what I said. Don’t stress about crafting the perfect alternative text. Just write it the way you would describe the photo of the bag of glistening diamonds you just stole from the Duke of Chauntelburry as you drive along the coast after finally shaking the detective, the wind blowing through your hair, with your getaway driver still chuckling about that dog-doing-chemistry meme you described to her earlier.

Learn More:

• Perkins School for the Blind, “How to Write Alt Text and Image Descriptions for the visually impaired”
• The A11y Project, “Are You Making These Five Mistakes When Writing Alt Text?”
• Axess Lab, “Alt-texts: The Ultimate Guide”
• Bureau of Internet Accessibility, “8 Common Image Alt Text Mistakes to Stop Making”
• Carie Fisher, “Accessible Images For When They Matter Most”
• Steve Faulkner, “The Perils of Using Double Quotes Inside Alt Text”
• Geoff Graham, “Just How Long Should Alt Text Be?”
• Stefan Judis, “The CSS ‘content’ Property Accepts Alternative Text”
• Shawn Lauriat, “How Learning ASL Improved My Alt Text”
• Veronica Lewis, “Seven Myths About Alt Text”
• Elaina Natario, “Alt vs Figcaption”
• Scott O’Hara, “Contextually Marking Up Accessible Images and SVGs”
• Adrian Roselli, “Long Alt”
• Wren, “An Attempted Guide to Writing Effective Alt and Descriptive Text for Art”

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

I think this sort of question would be a useful one:

"How would you attempt to build Wordle (...or some other complex app) if you could only use HTML and CSS? Which features of that app would make more sense to build with JavaScript than with other technologies? And, can you imagine a change or addition to the HTML or CSS standard that could make any of those features more straight-forward to build?"

Now, to be clear, this is meant to be a contrived exercise. I don't actually think a game app like Wordle should be built without using any JavaScript, (though I do think the app could be better if it functioned at all without it!). In reality, I feel there are many user experience enhancements to an app like Wordle that only JavaScript is capable of providing.

Still, I like this question as an exercise. Discussing any approaches to this challenge will reveal the candidate's broad knowledge of web standards–including new and emerging HTML and CSS features–and as a huge benefit, it would help select for the type of folks who are best suited to lead us out of the JavaScript over-reliance problems that are holding back the web today.

Interview questions aside though, I also thought this would be a fun little experiment to explore myself! So I took a few hours yesterday to do just that, and in the rest of this post I'll cover how I approached it.

A Quick Attempt

Here's a CodePen link with the demo and code for my first attempt:

Wordle, just HTML & CSS

By the way, if you aren't here to play games (or you want to save some time), you can find the answer to the puzzle in this little disclosure:

The approach I took for this example leans hard on HTML form validation for the game logic. I'm using a text input for each letter of the word, with pattern attributes describing the correct letter. The browser can natively use a pattern attribute to determine whether the input's value is "valid," which in the case of this contrived example can mean that a letter is correct.

To give an example, if the correct word was "TIGER" then the first letter's input could have a pattern attribute like this: pattern="[tT]" which would match lowercase and uppercase T. Additionally, the inputs have a maxlength attribute to limit their content length to 1 character.

HTML:

<input type="text" id="input1" name="input1" maxlength="1" pattern="[tT]">

Through these two attributes alone, we can already write a CSS selector to visually display whether a typed letter is correct or not, using a gray or green background similar to Wordle itself, like this:

input[type="text"]:invalid {
    background-color: lightgray;
}
input[type="text"]:valid {
    background-color: lightgreen;
}

Neat! But there are some problems.

Delaying Validation

As written above, the validation styles will show immediately as you are writing the letters, rather than after you type the entire word, which makes it too easy to change your answer as you see whether each letter is correct or not. That's not how Wordle works!

Instead, we want the validation to kick in only after a word is entered and complete. You could try to do this in a number of ways. I decided to use the :not() and :has() CSS selectors to qualify the validation styles to only apply when the user is done entering a whole word. The game board grid uses an HTML table element and each "word" row sits in a tr element. The following styles will apply to tr elements that do not contain focused or empty inputs, meaning every input has a character in it and the user is no longer typing in any of the inputs.

To gauge whether the inputs are empty, I added a placeholder attribute to the HTML input, which conveniently pairs with the :placeholder-shown selector that matches empty inputs. Here's the HTML and CSS:

HTML:

<input type="text" id="input1" name="input1" maxlength="1" pattern="[tT]" placeholder=" ">

CSS:

/* invalidate only non-focused populated row */
tr:not(:has(input:placeholder-shown, input:focus)) input[type="text"]:invalid {
    background-color: lightgray;
}
/* validate only non-focused populated row */
tr:not(:has(input:placeholder-shown, input:focus)) input[type="text"]:valid {
    background-color: lightgreen;
}

Nice. Now the form validation happens after a complete guess for each row. Small note: iOS Safari seems to only allow this selector to work with placeholder attributes that have at least some sort of string, so I added a blank space to its value, but there's probably a better character that I could use (maybe "A"?).

Disabling Future and Completed Rows

Another thing I wanted to do to match the game's behavior is to only allow interaction with the inputs in the active row. Admittedly, I didn't fully pull this one off for restricting keyboard focus, but I was at least able to disable touch and click-focus on those inputs by using a similar selector to the prior ones, and disabling pointer events.

/* disallow next row until row is populated */
tr:has(input:placeholder-shown) ~ tr input,
/* disallow revisiting populated row */
tr:not(:has(input:placeholder-shown, input:focus)) input {
    pointer-events: none;
}

Good enough, moving on.

Announcing a Win

When the correct word is typed, it would be nice to hide the rows after the correct guess and display a message that the game is over. To do this, I used a rule similar to the ones above, with some additional generated content to announce the win.

tr:not(:has(input:placeholder-shown, input:invalid, input:focus)) ~ tr {
    display: none;
}
table tr:not(:has(input:placeholder-shown, input:invalid, input:focus)):after {
  content: "You Win!";
  /* ...some additional less critical styles here */
}

Improvement to test: This winning announcement should be accessible, and I'm not sure that CSS generated content will be announced in assistive tech, even if I use an aria-live region. Perhaps it'd be better to toggle the CSS display of a status message that follows the table, or have a status column on the right with messages that can be revealed as needed. I'm thinking on this.

So What About Tan?

Now, admittedly, so far the game only offers the gray and green states of Wordle, which represent letters that are either not in the word at all (gray), or are entirely correct and in the right place (green). Unlike the real Wordle, it's missing the "tan" state that tells you a letter is in the word, yet in the wrong place. This means that the game is playable, but it's pretty hard!

Unfortunately, HTML validation only offers a binary answer, and what we really want here is a sort of in-between state that's valid but not super-valid.

Validating for Tan

So pattern validation only allows us to match for one type of pattern, but that pattern could refer to the whole word if we wanted to use it for the tan state instead of the green state. For example, the following pattern would match every letter in TIGER, both lowercase and uppercase: pattern="[tTiIgGeErR]".

Once again, our familiar CSS could target that valid pattern to color an input tan if it contains a letter that is in the word at all:

/* validate only non-focused populated row */
tr:not(:has(input:placeholder-shown, input:focus)) input[type="text"]:valid {
  background-color: tan;
}

So now our problem is tan works, but green doesn't. We need a little help showing the green state for letters that are not ONLY in the word, but in the right place as well.

Extending with JavaScript

Okay. Let's add some JavaScript to get 3 states instead of 2.

The following 10 lines add an input event handler (which fires whenever the user changes the input's value) to all of the inputs in the page. It will grab a regular expression pattern in that input's custom data-correct-pattern attribute and add a data-incorrect attribute to the input when the pattern doesn't match the input's current value:

document.querySelectorAll("input").forEach(inpt => {
  inpt.addEventListener("input", function(e) {
    const correct = this.value.match(new RegExp(this.getAttribute("data-correct-pattern")));
    if (correct) {
      this.removeAttribute("data-incorrect");
    } else {
      this.setAttribute("data-incorrect", true);
    }
  });
});

With that attribute toggle, I can write some CSS to add the green state! Here are my 3 states, the third of which using that new data-incorrect attribute:

/* invalidate only non-focused populated row */
tr:not(:has(input:placeholder-shown, input:focus)) input[type="text"]:invalid {
  background-color: lightgray;
}
/* validate only non-focused populated row */
tr:not(:has(input:placeholder-shown, input:focus)) input[type="text"]:valid {
  background-color: tan;
}
/* validate only non-focused populated row */
tr:not(:has(input:placeholder-shown, input:focus)) input[type="text"]:not([data-incorrect]) {
  background-color: lightgreen;
}

You can view the demo of this version here:

Wordle, almost just HTML & CSS

Caveats and Implementation Ideas

Needless to say, these examples don't do everything that the real Wordle does, so I won't attempt to itemize the differences here. Perhaps the most important difference to note is that there's no validation of real words, so you can enter any old letters you please.

I also want to explore how to make the state of the app persistently make sense to assistive technology, which might mean having an additional table column with cells containing the result of each validation (toggling the display of various possible messages so that they are accessible. Maybe that'll be a followup post (and if you're interested, here's a more practical article about improving actual-Wordle's accessibility).

Also, um, the puzzle is always the same answer? True! The real Wordle has a different word every day. A fuller implementation of an approach like this would need some dynamic handling on the server side to deliver different HTML patterns for the word of the day.

Having said all of that, I find it pretty awesome that HTML and CSS alone can get us so far today, and it's totally possible that there are different HTML patterns that could pull off all 3 colors without JS already, as well (perhaps if we built a large QUERTY keyboard out of radio inputs...)

What if :valid was a function?

Okay, as for the the last part of my original question. What could be added to HTML or CSS to make that last example possible without JavaScript? One thing comes to mind for me: an ability to validate multiple patterns on one input.

For example, let's revisit that pattern attribute value. The existing pattern="[tTiIgGeErR]" will match for all of the letters in the word Tiger, uppercase or lowercase. From that, you get a simple yes or no match for whether the letter is in the word at all, again like this:

input[type="text"]:valid {
  background-color: tan;
}

That gives us the tan color, but again we still have the green pattern to worry about. What if that :valid pseudo-class allowed for arguments, though? If it did, then I could pass a string to it, like :valid("[gG]") to specifically match for a g or G. Even better, maybe the value could accept the standard CSS attr() function too, which would allow the HTML to define additional patterns for the CSS to validate. In my second demo, I used a data-correct-pattern attribute to define that second pattern.

Here's how the markup and CSS might look for that dreamed-up feature, which could allow the second demo to work without JS:

HTML:

<input type="text" id="input1" name="input1" maxlength="1" pattern="[tTiIgGeErR]" data-correct-pattern="[tT]" placeholder=" ">

CSS:

/* invalidate only non-focused populated row */
tr:not(:has(input:placeholder-shown, input:focus)) input[type="text"]:invalid {
  background-color: lightgray;
}
/* validate only non-focused populated row */
tr:not(:has(input:placeholder-shown, input:focus)) input[type="text"]:valid {
  background-color: tan;
}
/* validate only non-focused populated row */
tr:not(:has(input:placeholder-shown, input:focus)) input[type="text"]:valid(attr(data-correct-pattern)) {
  background-color: lightgreen;
}

JavaScript:

...none needed.

Maybe I'll file an issue in the CSS standard asking for :valid(attr(...))! :)

Thanks!

I hope you enjoyed this post. Please feel free to reach out with ideas or questions or improvements on Mastodon. Thanks for reading!

See also: Scott's post Popping preconceived popover ponderings and Hidde's talk on popovers, and other posts about popover semantics, positioning popovers and the difference with dialogs and other components.

Accessibility semantics

The “built-in” accessibility of popover is in the addition of guardrails: browsers try to improve accessibility where they can. These guardrails exist mostly in the form of browsers augmenting accessibility semantics. Before we get into what those guardrails are, let's clarify what that term means.

Many features of HTML have some amount of accessibility semantics associated with them - e.g., roles, states and properties. This is information that a web page exposes, which browsers then pass on to platform accessibility APIs. They do this, so that assistive technologies can build UIs around them (see: How accessibility trees inform assistive tech). These semantics are sometimes baked into native HTML elements. For instance, headings and lists have implicit roles (heading and list, respectively). Other elements, like the checkbox input type, have an implicit role as well as additional states and properties. Developers can use HTML elements with such “built-in” semantics. But they can also set, overwrite and augment accessibility semantics more directly in their HTML structure, using WAI-ARIA.

The thing with the popover attribute is that it doesn’t have a built-in role. After all, it’s not an element. Its purpose is to only add “popover behaviour”, as discussed in Popover semantics. In that sense, popover is a bit like tabindex or contenteditable. These attributes also add behaviour: tabability and editability behaviours, respectively.

A major reason for this choice is that there are a number of components that exhibit popover behaviours. Examples include menus, “toast” messages, sub-navigation lists of links and tooltips. You can use popover on a specific element, then it will get that element's role. Or you can use it with a generic element, and add a role that best matches what you are building.

So, while the default role is ‘generally’ not handled by the attribute (more on that later), there are other semantics (properties and states) that the attribute will expose. Browsers can take care of those with some degree of confidence.

What browsers do

There are two semantics that the browser should take care of when you use popover, and its associated popovertarget attribute. Additionally, there is some keyboard focus behaviour that may also be handled automatically, depending on the type of popover you are using.

The aria-expanded state

First, aria-expanded. This state is exposed on the element that invokes the popover, currently limited to buttons (for a variety of reasons that would require a whole other article to talk about - so this is all you get right now). When a popover is invoked by / associated with a button with the popovertarget attribute, the browser will automatically convey whether the popover is in the expanded (rendered) state, or if it is in the collapsed (hidden) state. This is implemented in Edge, Chrome, Firefox and Safari.

For the following example, the ‘heyo’ button will automatically convey whether its associated popover list is in the expanded or collapsed state, based on whether the popover list is invoked as a popover.

<button popovertarget=p>
  Heyo
</button>

…

<ul 
  aria-label="Heyo subpages" 
  id=p 
  popover
></ul>

Note: the state won’t be applied if script, rather than the declarative attribute, does the opening on click of any button (or any other element). Needless to say: it also doesn’t work if there isn’t an invoking button, for instance, and script invokes this popover (because in that case, there isn’t any expanding going on). Additionally, if you force open your popover using CSS display block, then it will not be rendered as a popover - and thus the button will still communicate that the “popover” is in the collapsed state. Also, if you’re doing that - forcing your popover open with CSS - maybe you have some things you need to reconsider with your UI.

The aria-details relationship

When the popover doesn’t immediately follow its invoking button in the accessibility tree, browsers are supposed to create an aria-details relationship on the popover’s invoking button with its associated popover. At the time of writing, this is implemented in Chrome, Edge and Firefox.

For instance, in the following markup snippet an implicit aria-details relationship will be made with the button that invokes the popover, because the button and the popover are not immediate siblings in the accessibility tree.

<button popovertarget=foo>something</button>

<p>...</p>

<div role=whatever popover id=foo>...</div>

Similarly, an aria-details relationship will be made with the next markup snippet too, because even though the popover and its invoking button are siblings, the popover is a previous sibling to the invoking element, and it might not be understood which element is the popover, because it doesn’t immediately follow the element that invoked it.

<div role=whatever popover id=foo>...</div>

<button popovertarget=foo>something</button>

In contrast, the next two examples have no aria-details association because that would be unnecessary. For the first, the popover is the immediate next sibling in the accessibility tree (note divs are generic and often ignored when they do not provide information important to accessibility). For the second, the button is a descendant of the popover, so browsers do not need to tell users that the button they are interacting with is about the context they are within. That’d be silly.

<!--  
  example 1: 
  popover immediate sibling in acc tree 
-->
<button popovertarget=m>something</button>
<div class=presentational-styles-only>
  …
  <div role=menu popover id=m>...</div>
</div>

<!-- 
  example 2:
  button descendant of popoover
-->

<dialog popover id=d>
  <button popovertarget=d>close</button>
  …
</dialog>

For more information on how aria-details works, check out the details in the ARIA spec.

Note: aria-details is often confused with aria-describedby. That makes sense, “details” and “descriptions” are very similar. However, these two properties expose different information. aria-describedby takes the associated element’s content, flattens it into a single text string, and exposes that as the ‘description’ or ‘hint’ of the element which the attribute is specified. In contrast, aria-details only informs a user that there is additional information about the current element. That might not seem useful, until you know that screen readers largely provide quick-keys to navigate to and from that associated element which provides the details.

At the time of writing, navigating into the referenced content using quick-keys is supported by JAWS and NVDA (release notes), but not VoiceOver.

Here’s a quick demo of that with JAWS 2023 in Edge 124. JAWS lets us jump to the details content if we press Alt + Ins + D:

In NVDA (2023.3.4), tested with Edge 124, it works slightly differently: when you press the shortcut (NVDA + D), we don't jump to the details content, but it is read out after the shortcut is pressed:

(see demo on CodePen; note: announcements and shortcuts depend on the user's settings, versions, etc)

In the following demo, you can see how the aria-details relationship works between popovers and their invokers (in JAWS 2023 with Edge 124):

(video contains screenshot of code, see demo on CodePen)

In summary: the aria-details association is not announced by JAWS when we focus the invoking button for the first time. This is because the corresponding popover is hidden, so the association isn't made yet. After we open the popover, JAWS announces the button's “has details” association while it is open, to hear it we navigate away and back. This is also how it works in NVDA, which, in addition, also requires you to switch to forms mode to actually hear the relationship announced.

Warning: even if the aria-details association is implemented, it may not be completely ironed out in how the UX behaves for people. For instance, there isn't currently a way for users to find out about the details relationship once it is established, like when the popover opened. It requires for the user to move away from the button and return to it, at which point the relationship is announced. Maybe it would be helpful if the browser would fire some kind of event, to let AT like JAWS know that an element representing details has appeared.

We mention this not to deter you from using popover or to indicate that anyone is doing something “wrong” here. Rather, this is a relatively new feature that people still need to figure out some of the UX kinks around. Feedback is welcome, and to help ensure the best UX is provided, please reach out to the necessary browsers / AT with your thoughts.

The group role

As mentioned above, popover can be used on any element, including elements that don’t have a built-in role, like div. But even without a role, it’s likely that the contents of a popover form some kind of meaningful whole. This is why in Chrome, Edge and Firefox, a role of group is automatically added to popovers if they would otherwise have no role, or a role of generic (for instance, divs and spans).

The group role is added, so that assistive technology can have the option to expose the boundaries of the popover that is being displayed. This can be important to users, because a popover is a behavior and visual treatment of its content. How is one to know where such content begins or ends if it doesn’t have boundaries to expose?

It’s important to know that an unnamed group is often ignored by screen readers. This is because otherwise the Internet would be riddled with unhelpful “group” announcements. (See also why Webkit made the decision to remove list semantics from lists that have been styled to not look like lists. These topics are related). Here though, it again comes down to what assistive technology wants to do. By exposing the group role for the popover, now the element can be named by authors, which will force the group role to be exposed in most cases. Then, if AT decided they want to do something special for popover groups, they now have the opportunity to do so.

Keyboard accessibility

One more aspect of “built-in accessibility” that browsers do for your popover, is take care of some keyboard behaviors.

Moving focus back to invoking element

Edge/Chrome, Firefox and Safari will all return focus to the invoking element when you close the popover (only if you are inside of it). This is useful, because if focus was on an element inside the popover, the default would be to return focus to the start of the document. Various groups of users would get lost, increasingly so on pages with a lot of content. Moving focus back to the invoking element helps ensure people can quickly return to what they were doing, rather than spending time having to re-navigate to where they think they were last.

Popover content in tab order

Desktop browsers also do something else: they add the popover content into the tab order just after the invoking button. Even if that’s not where the popover is in the DOM.

Imagine this DOM structure:

<button popovertarget=p>Open popover</button>

<p>content… content… <a href="#">link 1</a></p>

<p>content… content… <a href="#">link 2</a></p>

<div popover id="p"><a href="#">link 3</a></div>

When the popover opens, and you press Tab, you might think you’d jump to “link 1”, the next interactive element in the DOM. Except, in desktop browsers, you will jump to “link 3” instead. The browser basically moves the popover content’s position in tab order to just after its invoking button. This takes it out of its expected position in the tab order. That improves the user experience, because it is likely that upon opening the popover, users will want to interact with its contents.

Keep in mind: browsers adjust the Tab order for instances like this, but they don't adjust the placement of the content in the accessibility tree. This is why the aria-details association was implemented. This special Tab order behavior helps ensure logical focus order for keyboard accessibility. However, we should still strive to make sure our popovers come after the invoking element in the DOM.

But since there will be times where the exact location of the popover in the DOM may be out of one’s control, this behavior is still quite welcome. For instance, if the popover happens to be far away in the DOM, having to go through the rest of the document before reaching the popover would be a nuisance. It would be highly unexpected and unwanted to have to navigate through all other focusable elements in the DOM, prior to the popover one just opened. WCAG 2.4.3 Focus Order requires focusable elements to receive focus in an order that “preserves meaning and operability”. This special browser Tab restructuring helps ensure that requirement can be met.

What browsers don’t do

We can keep this one short: the browser will not do anything apart from the behaviours listed above. Browsers will not add behaviors based on which elements you use or which role you add to them. The popover attribute is merely a first step for us to build new components.

Conclusion

The popover attribute provides a starting point for building popover-like interactions on the web. Browsers don't magically make your components accessible, that's not a thing. But there are some specific keyboard behaviours included with popover, as well as these semantics:

• In specific cases, browsers set the aria-expanded state and/or set the aria-details relationship on the invoker.
• Browsers apply the group role to the popover content if it doesn’t have a role of its own, so that assistive technologies can expose their boundaries.

Browser support note: at the time of writing, Safari only sets aria-expanded, not aria-details. It also doesn't add a group role fallback.

Originally posted as On popover accessibility: what the browser does and doesn’t do on Hidde's blog.

Reply via email

~

~

# Table of Contents

• Custom Highlight API 101
• Browser support
• Syntax Highlighting Static Code Snippets
  • How it works
    • Step 1: Setting up shop
    • Step 2: Tokenizing the code
    • Step 3: Associating the tokens with the highlights
• The downsides of the Custom Highlight API
  • Limited Styling Options
  • No textareas
  • No pointer events (yet)
  • (Chrome/Firefox Bug) Color information gets lost on selecting text
  • (Chrome/Safari Bug) Performance regression with many highlights
• On-the-fly syntax highlighting of [contenteditable] code snippets
• In Closing
• Spread the word

~

# Custom Highlight API 101

The CSS Custom Highlight API offers a mechanism for styling arbitrary ranges of a document identified by script.

Custom highlights are represented by Highlight objects. These objects hold one or more Ranges that identify which parts of the text should be highlighted. Finally, these Highlights need to be registered into the highlight registry so that you can style them from within CSS.

In code:

// Create Highlight
const h = new Highlight();

// Add ranges to the Highlight
const r1 = new Range();
r1.setStart(text.firstChild, 13);
r1.setEnd(text.firstChild, 28);
h.add(r1);

const r2 = new Range();
r2.setStart(text.firstChild, 38);
r2.setEnd(text.firstChild, 56);
h.add(r2);

// Register the highlight into the registry
// This makes the ::highlight() CSS work
CSS.highlights.set('example', h);

That last line enables the use of ::highlight(example) in your CSS to style the highlight:

::highlight(example) {
	color: hotpink;
}

You can see this code in action in this technical demo. Characters 13-28 and characters 38-56 get the hotpink color applied because they got added to the example Custom Highlight.

See the Pen CSS Custom Highlight API Example by Bramus (@bramus)on CodePen.

It is possible to register multiple highlights via CSS.highlights.set, as long as they have a different name. A Range can be added to multiple highlights – so all styles get applied – and ranges can also overlap.

A typical use-case to using the Custom Highlight API would be to highlight search results as you type in a text input. The following demo by Jen Simmons shows this:

See the Pen Custom Highlights demo by Jen Simmons (@jensimmons)on CodePen.

~

# Browser support

Here is an up-to-date list of browser support for the CSS Custom Highlight API:

Chrome (Blink)

✅ Supported as of Chrome 105

Firefox (Gecko)

👨‍🔬 Experimental support in Firefox Nightly

Safari (WebKit)

✅ Supported as of Safari 17.2.

The pen embedded below will indicate if the browser you are currently using supports the CSS Custom Highlight API or not:

See the Pen CSS Custom Highlight API Support Test by Bramus (@bramus) on CodePen.

To stay up-to-date regarding browser support, you can follow these tracking issues:

• Chrome (Blink): Issue #40163546 — Fixed
• Firefox (Gecko): Issue #1703961 — ASSIGNED
• Safari (WebKit): Issue #204903 — RESOLVED FIXED

~

# Syntax Highlighting Static Code Snippets

During one of the conversations at the most recent CSS Working Group F2F meeting in Mountain View, Emilio (Firefox) and Tab (Google) came up with the idea to use the Custom Highlight API to do syntax highlighting.

Taking their idea for a spin, I whipped up this CodePen. The Pen acts as its own demo: the CSS and JavaScript you see on the page is the actual code that gets executed and thereby syntax highlighted.

See the Pen Syntax highlighting code blocks with Prism and the Custom Highlight API by Bramus (@bramus) on CodePen.

script[visible], style[visible] {
	display: block;
	white-space: pre;
	font-family: monospace;
	overflow-x: auto;
	… 
}

~

# How it works

At its core, the demo consists of three steps:

1. Register Custom Highlights for all possible token types
2. Tokenize the code
3. Associate the extracted tokens with the relevant Custom Highlight

~

# Step 1: Setting up shop

For each token type that there is in JavaScript and CSS – the two languages the demo needs code highlighting for – the demo sets up a ::highlight pseudo:

/* From prism.css */
::highlight(parameter) {
	color: #1a1a1a;
}

::highlight(comment), ::highlight(prolog), ::highlight(doctype), ::highlight(cdata) {
	color: slategray;
}

::highlight(punctuation) {
	color: #999;
}

::highlight(property), ::highlight(tag), ::highlight(boolean), ::highlight(number), ::highlight(constant), ::highlight(symbol), ::highlight(deleted), ::highlight(class-name) {
	color: #905;
}

::highlight(selector), ::highlight(attr-name), ::highlight(string), ::highlight(char), ::highlight(builtin), ::highlight(inserted) {
	color: #690;
}

::highlight(operator), ::highlight(entity), ::highlight(url) {
	color: #a67f59;
	background: hsla(0, 0%, 100%, 0.5);
}

::highlight(atrule), ::highlight(attr-value), ::highlight(keyword) {
	color: #07a;
}

::highlight(function) {
	color: #dd4a68;
}

::highlight(regex), ::highlight(important), ::highlight(variable) {
	color: #e90;
}

::highlight(important), ::highlight(bold) {
	font-weight: bold;
}

::highlight(italic) {
	font-style: italic;
}

::highlight(entity) {
	cursor: help;
}

The CSS is useless without having registered the custom highlights, so to make them usable you need to register 1 highlight for each token type:

const tokenTypes = [ 'comment', 'prolog', 'doctype', 'cdata', 'punctuation', 'namespace',
	'property', 'tag', 'boolean', 'number', 'constant', 'symbol', 'deleted',
	'selector', 'attr', 'string', 'char', 'builtin', 'inserted', 'operator',
	'entity', 'url', 'string', 'atrule', 'attr', 'keyword', 'function', 'class',
	'regex', 'important', 'variable', 'important', 'bold', 'italic', 'entity',
	'parameter', 'class-name'];

tokenTypes.forEach(tokenType => {
	CSS.highlights.set(tokenType, new Highlight());
});

~

# Step 2: Tokenizing the code

To do the tokenization, I rely on the wonderful Prism.js. Since I only need the tokenizer, Prism is loaded in manual mode so it doesn’t try to do its own thing on load.

<script src="prism.js" data-manual></script>

With Prism loaded in manual mode, you can run its tokenizer on demand:

// Get all inlined script and style blocks
const codeBlocks = document.querySelectorAll('script[visible], style[visible]');
		
// Loop ’m one by one
for (const codeBlock of codeBlocks) {

	// Tokenize it.
	// When it’s a STYLE element, tokenize it as CSS. Otherwise, assume JavaScript.
	let tokens = Prism.tokenize(
		codeBlock.innerText,
		codeBlock.tagName == 'STYLE' ? Prism.languages.css : Prism.languages.javascript
	);

	// …
}

Calling Prism.tokenize gives back a list of tokens that holds information about which token is where. For example:

[
	{
		"type": "keyword",
		"content": "const",
		"length": 5
	},
	" name ",
	{
		"type": "operator",
		"content": "=",
		"length": 1
	},
	" ",
	{
		"type": "string",
		"content": "\"Bramus\"",
		"length": 8
	},
	{
		"type": "punctuation",
		"content": ";",
		"length": 1
	}
]

~

# Step 3: Associating the tokens with the highlights

To associate the extracted tokens with their relevant highlight, it’s a matter of looking all tokens and determining their start and end position within the original source code.

// Position within the code
let pos = 0;

// Loop all tokens
for (const token of tokens) {
	if (token.type) {
		// Create new range for the current token
		const range = new Range();
		range.setStart(codeBlock.firstChild, pos);
		range.setEnd(codeBlock.firstChild, pos + token.length);

		// Add the range to the registered highlight
		CSS.highlights.get(token.alias ?? token.type)?.add(range);
	}

	// Update position
	pos += token.length;
}

And with that, the code snippets are syntax highlighted using the CSS Custom Highlight API 🙂

~

# The downsides of the Custom Highlight API

Unfortunately it’s not all rainbows and unicorns with the Custom Highlight API, as it comes with some limitations and has some implementation bugs.

~

# Limited Styling Options

Just like the case with regular highlights, the styling of highlights is limited to only a small set of CSS properties that do not affect layout. Only allowed properties are color, background-color, text-decoration, text-shadow, stroke-color/fill-color/stroke-width, and custom properties.

That means you can’t change text to be bold or italic, something is often used when highlighting code snippets. At the CSS WG, w3c/csswg-drafts#8355 was raised to see if more styles could be allowed or not.

~

# No textareas

Custom Highlights don’t work on textareas. I’m not entirely sure if this is an implementation bug of a limitation of the spec. I’ve filed w3c/csswg-drafts#9971 at the CSS WG to discuss this.

~

# No pointer events (yet)

Any of the Custom Highlights don’t have pointer events. That means that if you, for example, hover a Custom Highlight, you can’t show a tooltip when hovering that specific highlight.

The CSS Working Group has resolved on adding CSS.highlights.highlightsFromPoint(x, y) that would eventually allow this. It would work something like this:

document.addEventListener("click", function(e) {
	if (e.defaultPrevented) {
		return;
	}

	for (let highlight of CSS.highlights.highlightsFromPoint(e.clientX, e.clientY)) {
		highlight.dispatchEvent(e);
		if (e.defaultPrevented) return;
	}
});

Problem at the time of writing is that this feature is still in its very early stages: it lacks a specification, tests, and – more importantly – an implementation.

~

# (Chrome/Firefox Bug) Color information gets lost on selecting text

Both in Chrome and Firefox there is a loss of color information when selecting text that has custom highlights. Safari is not affected by this.

For Chrome specifically, I have filed CrBug 325442893 for this.

~

# (Chrome/Safari Bug) Performance regression with many highlights

Highlighting something like the jQuery Source Code with Custom Highlights takes its toll on the browser. Highlighting the 63338 tokens that make up the unminimized jQuery 3.7.1 source code is possible but when performing a scroll, the performance just tanks.

This drop in scroll performance is noticeable in Chrome and Safari; Firefox seems to deal with it pretty much fine. Chrome 122 performs the worst here, but Chrome 124 (current Canary) already sports some good improvements in this area.

For Chrome specifically, I have filed CrBug 325589486 for this.

~

# On-the-fly syntax highlighting of [contenteditable] code snippets

With not being able to use the Custom Highlight API textarea elements, I wondered if we could make a on-the-fly syntax highlighter using a <pre> element with [contenteditable].

The short answer here is yes, as demonstrated in the following demo. Every time you type in a character, the current highlights get cleared, the code re-tokenized, and the new highlights get applied.

See the Pen On-the-fly Syntax Highlighting of [contenteditable] by Bramus (@bramus) on CodePen.

The long answer is creating this editor came with a set of complications introduced by [contenteditable] itself.

The first thing I had to do was disable rich text editing which [contenteditable] gives you out-of-the-box – e.g. hitting CMD+B allows making text bold. This can easily be disabled by setting the value of [contenteditable] to plaintext-only. Firefox doesn’t support this value but does support [contenteditable=true] so that browser gets a special treatment

// The pre element that can be edited
const codeBlock = document.querySelector('pre[contenteditable]');

// Allow only plaintext editing
// Firefox doesn’t do 'plaintext-only', but does do 'true'
codeBlock.setAttribute('contenteditable', 'plaintext-only');
if (codeBlock.contentEditable != 'plaintext-only') {
	codeBlock.setAttribute('contenteditable', 'true');
}

The biggest challenge was that [contenteditable="plaintext-only"] still uses HTML breaks from time to time and also creates new text nodes in the <pre> element whenever you hit return.

To cater for this I ended up adding some logic that would flatten the number of text nodes to just 1 before the tokenizing step. This also required me to add some extra logic to make sure the curser position is retained.

const flattenTextNodes = codeBlock => codeBlock.normalize();

// Helper function to get the caret position inside an element
// Plays nice with an element having multiple text nodes as its children
const getCaretPosition = (el) => {
	const selectionInfo = window.getSelection(el);
	let node = selectionInfo.anchorNode;
	let pos = selectionInfo.anchorOffset;

	// Need to loop all previous siblings here becase you only get the position
	// in the current text node, so we need to offset the previousSibling here
	// TODO: This might need a rewrite to make sure it only loops textNodes
	while (node.previousSibling) {
		pos += node.previousSibling.length;
		node = node.previousSibling;
	}

	return pos;
}

// Helper function to flatten the text nodes in an element to
// only 1
const flattenTextNodes = (codeBlock) => {
	if (codeBlock.childNodes.length > 1) {
		// Record current caret position
		const caretPosition = getCaretPosition(codeBlock);

		// Set firstChild to hold the whole text
		codeBlock.firstChild.textContent = codeBlock.firstChild.wholeText;			

		// Remove all other text nodes
		let node = codeBlock.firstChild;
		while (node.nextSibling) {
			codeBlock.removeChild(node.nextSibling);
		}

		// Restore caret position
		// @TODO: There is 1 little bug: when selecting the entire last line and hitting
		// backspace, you end up at position 0;
		window.getSelection(codeBlock).setPosition(codeBlock.firstChild, caretPosition);
	}
}

This flattenTextNodes helper gets called right before the code gets tokenized. It gets the job done, but also introduces FOUC upon adding lines to the [contenteditable]

The combined code to highlight a codeBlock becomes this:

const highlight = (codeBlock, lang = Prism.languages.javascript) => {
	// We need the contenteditable to hold only 1 child textNode that
	// contains all the text. If we don’t do this, the highlight ranges
	// might go out of bounds.
	flattenTextNodes(codeBlock);

	// Tokenize the code
	let tokens = Prism.tokenize(
		codeBlock.innerText,
		lang
	);

	// Clear all current highlights
	tokenTypes.forEach(tokenType => {
		CSS.highlights.get(tokenType).clear();
	});

	// Paint all token highlights
	paintTokenHighlights(codeBlock, tokens);
}

For completeness, I also added a little tad of JS to map the TAB key to actually inserting a TAB character:

codeBlock.addEventListener('keydown', e => {
	// The tab key should insert a tab character
	if (e.keyCode == 9) {
		document.execCommand('insertHTML', false, '	');
		e.preventDefault();
	}
});

~

# In Closing

I must say I’m pretty excited about the Custom Highlight API and what it allows to do. However, I do hope some of the current gaps can be fixed to make this API workable under all conditions. [contenteditable] in itself could also use some love and interop-pushing.

~

# Spread the word

To help spread the contents of this post, feel free to retweet the announcements made on social media:

Y’all seem to like the posts on using the Custom Highlight API with @prismjs to syntax highlight code …

So here’s a full article digging into the details + a new demo that does on-the-fly highlighting of code you type into a [contenteditable] element.https://t.co/d98PVlHPKh pic.twitter.com/bjH3rHhhy6

— Bramus (@bramus) February 18, 2024

~

I really enjoyed this well-reasoned article explaining why htmx, the open-source hypermedia JS framework, does not have a build step.

I liked that the premise – “we don’t have a build step” — is not presented as a universal truth for its readers — “therefore you shouldn’t have a build step”.

Instead, the author outlines the benefits and tradeoffs of their approach. The article is not, “This is what everyone should do”, but rather, “This is what we do for this project for these reasons and with these trade-offs, which fits our context. Perhaps you might be in a similar situation.”

The htmx DX is very simple—your browser loads a single file, which in every environment is the exact same file you wrote. The tradeoffs required to maintain that experience are real, but they’re tradeoffs that make sense for this project.

Granted, the power to cheat entropy by writing code as it will be run comes with a cost — and that cost is often paid by you the programmer. Perhaps that is why we have so much “innovation” in the DX space: to make our lives easier (but not necessarily our websites better).

In fact, it almost makes you wonder if all the innovation in DX and web tech has a parallel to those startups which solve trivial problems that only address the superficial annoyances of our lives, like being able to order any food at any hour and have it delivered directly into your lap. Or a machine to squeeze juice out of a bag. Living without those is annoying to my laziness, but in lived experience it’s not that big of a deal.

every line of htmx has to be written in IE11-compatible JavaScript, which means no ES6...While this is incredibly annoying, in practice it is not a huge impediment.

I love the pragmatism here. “While not being able to use shiny new thing is incredibly annoying, in practice it’s not that big of a deal.”

And I haven’t even got to the “no build step” part yet!

Ok so why is writing code as it will be run so amazing? Well, for one, vanilla JavaScript lasts forever:

The best reason to write [anything] in plain JavaScript is that it lasts forever. This is arguably JavaScript’s single most underrated feature…JavaScript from 1999 that ran in Netscape Navigator will run unaltered, alongside modern code, in Google Chrome downloaded yesterday

Contrast that with JavaScript (or CSS) that requires a compilation/transpilation step. Those often have the shelf-life of a dairy product.

most people’s experience with JavaScript is that it ages like milk. Reopen a node repository after 3 months and you’ll find that your project is mired in a flurry of security warnings, backwards-incompatible library “upgrades,” and a frontend framework whose cultural peak was the exact moment you started the project and is now widely considered tech debt

There’s a cost to writing code that must be transformed before it can be run, and (as Rich said) I think people are in denial about the costs toolchains impose on them — or maybe even unaware of them.

Maintenance is a cost paid for with labor, and open-source codebases are the projects that can least afford to pay it

As the author notes, a big reason we’re (willingly or unknowingly) blind to the costs of our toolchains is because we hold this unspoken belief in technology that change, any change, constitutes progress.

the tendency of software engineers to view progress as a teleology of capability rather than choices with tradeoffs sometimes blinds them

But that blinds us to so many of our own ailments — “Doctor it hurts when I touch here / then don’t touch there!” For example, sometimes we are so willing to pickup and use the gateway building blocks to complexity in order to avoid the slightest bit of annoyance.

Modules are really useful.

Sometimes, however, you want to solve simple problems, or at least relatively simple problems. In those cases, it can be helpful not to use the building blocks of more complex software, lest you emulate their complexity without creating commensurate value.

Perhaps a little constraint could go a long way. As Devine said, “I don't think we've even begun to scratch the surface with what can be done with little.” Especially at the cost of a little annoyance to ourselves.

• Reply via: Email, Twitter, Mastodon

textarea {
  form-sizing: normal;
}

I came across it via an Amit Merchant blog post. Then followed the thread a little. It all started with a discussion, as these things tend to in this modern world. I think it’s a super weird name choice, but I’m sure if you were super involved in that discussion it would all make sense.

I was surprised to see it already in Chrome Canary with the “web experiments” flag enabled. Of course Adam is all over it:

So useful, good job CSS.

Who knows when that will be usable across all browsers, or if it will definitely ship just like that. I tend to agree with Lea Verou earlier in the discussion that height: max-content feels like a very elegant choice, but I’m not privy to why they didn’t go that way. Also like Lea, if this opens the door for horizontally growing single-line inputs, that’s a win.

My favorite trick of doing this before was using CSS grid. You’d take the text inside the textarea and propagate it to a hidden psuedo element overlaid exactly on top. That stack technique is a classic:

.grid {
  display: grid;
  grid: stack;
  > *, &::after {
    grid-area: stack;
  }
}

Credit to Stephen Shaw on the original idea for that.

User-agent: GPTBot
Disallow: /

That felt a bit “ex post facto“ as they say. Or, as Jeremy put it, “Now that the horse has bolted—and ransacked the web—you can shut the barn door.”

But folks seemed to be going ahead and doing it anyway and I thought to myself, “Yeah, I should probably do that too…” (especially given how “fucking rude” AI is in not citing its sources).

But I never got around to it.

Tangentially, Manuel asked: what if you updated your robots.txt and blocked all bots? What would happen? Well, he did it and after a week he followed up. His conclusion?

the vast majority of automated tools out there just don't give a fuck about what you put in your robots.txt

That’s when I realized why I hadn’t yet added any rules to my robots.txt: I have zero faith in it.

Perhaps that faith is not totally based in reality, but this is what I imagine a robots.txt file doing for my website:

• Reply via: Email, Twitter, Mastodon

This made me wonder why the same isn’t true for websites.

The baseline for websites is not great. Okay, fine: most websites are pure, unadulterated, straight-up bad. Bad from top to bottom, bad from left to right. There’s no denying it, as much as I might want to. And I do want to! I want to hold up the field of web design and say that it’s en par with what musicians and painters and everyone else is doing in every other field. I’ve dedicated my life to this thing and so when I find a beautiful website, something that pushes the whole thing forwards, I want to loudly celebrate it.

I truly want every website to be worthy of our browsers.

But modern websites are not worthy. They’re slow, hard to navigate, and plagued with visual crap; pop-ups, bad typography, newsletter modals, and everything else imaginable. And that’s just the baseline. When I use a website on my phone I likely won’t trust it to show me the same information, I won’t trust interactions when I click buttons or fill in forms or even when I try to navigate elsewhere.

I don’t even trust the back button any more.

It’s so bad that visiting a website in 2023 is like falling into a blackhole and being hit by a bunch of random junk on your way to being crushed into an infinite nothing in the center. No, I don’t want to give you permission about cookies, no I don’t want to sign up to your newsletter, no I don’t want to talk with some half-baked chatbot.

No, no, no.

This low bar for web design is what makes me embarrassed to call myself a web designer. If you tell a stranger that you make websites for a living then their first thought is likely “that sounds lame.” Would they think the same of a book designer? Or a graphic designer? They might not be interested, they might yawn, but they wouldn’t be embarrassed for you.

And yet! I do truly believe that a website can be as well designed as any book, just as thoughtful, just as brilliant. Yet in 2023 it feels like we’ve let websites be one of two things: either confused, junky bloatware or simple white posters with black text and a big checkout button. But the web can be so much more!

When I find a website that doesn’t hijack the scroll, or a website with pleasantly sized text, or a website that loads in under 300ms then it makes me bolt upright in my chair. I wonder at what tech they’re using under the hood, what kind of conversations they had in those rooms, I try to imagine what kind of grueling process the team went through to make something so quiet and simple. All the things they had to say no to.

The other day Chris Coyier mentioned that bad software is an opportunity: if everyone else is making stuff that sucks and you don’t, you’ll have a leg up. And I get that, I think it’s true. If people look at your software as stable and reliable and trustworthy then you’ve already kinda won. But still, I can’t help feel that bad software is also an excuse. Everyone else’s websites don’t load in under 1 second, so why should mine? I don’t use my website on mobile, so who cares for those who do? Fixing this accessibility problem will only help one person, how does that make us money?

It matters because of the baseline! Every decision we make sets expectations of what is acceptable and what ain’t. Every time we say yes to shitty design and inaccessible text inputs we lower the floor for the whole profession, the whole art form of web design. Saying yes to one terrible new analytics script opens the door to ten thousand more.

So why is web design embarrassing? Why is the floor so low? And why do folks not see the web the same way I do, as a place to be treasured and cared for in the same way as a beautiful book?

I have two reasons beyond the obvious answers.

First, I think great web design requires discipline. And that’s really the hardest thing about making a website. In this field there are a thousand yes’s for every no because, and here’s the second reason: it’s impossible to hold a website in your hand. It’s hard and sometimes tedious to see all the variations of your work across the infinitude of devices and circumstances that might touch your site. When making a website it sometimes feel like you’re thinking in four dimensions instead of three.

But really the baseline of web design is so low because there’s a lack of tenderness, care, and empathy. It’s because we don’t see the making of a website as a worthy profession. It’s because we hope to squeeze the last bit of juice from the orange by mulching people in between modals and pop ups and cookie banners.

So how do we do better? How do we take better care of our websites?

Using one element or set of elements (usually because of their functionality) and styling them to look like something else is a common pattern. A recent conversation on Twitter about using radio buttons styled to look like buttons highlighted the essential problem with this approach - it creates a mismatch between the actions people expect they can take and the ones they actually can.

Affordance

The concept of "affordance" was first described by JJ Gibson in the late 1970s and Don Norman applied it to design in the late 1980s. Norman later used the phrase "perceived affordance" to clarify the use of affordance in interface design. Perceived affordance, as Norman puts it, is "whether the user perceives that some action is possible (or in the case of perceived non-affordances, not possible)".

For example, a button is intended to be pressed with the expectation that something will happen when it is. When a button is not pressed it stands proud of the surrounding surface, and when it is pressed it's flat. This means you can tell that it's a button and what state it's in by touching it or by looking at it. In other words, a button has both physical and perceived affordances. The knowledge of what to do with it comes from your prior experience of using buttons that conform to the same convention.

The concepts of affordance and convention were so familiar to most people, they were transferred from the physical world to digital. Radio buttons, for example, are so called because of car radios from the days before digital broadcasting.

Finding a radio station used to involve twiddling a knob to slowly move through the different radio bands until you found a station you wanted to listen to. Doing this whilst driving and, presumably, wanting to keep your eyes on the road, was not altogether conducive to an accident free life, so radio buttons were invented. Car owners could pre-tune their radio to a few favourite stations and assign each station to a button on the front of the radio. Since listening to one station at a time is enough for most people, the radio buttons were designed so that only one could be pressed at a time.

Perception

The digital world still hasn't really figured out physical affordance, at least not to the extent it's useful across websites and applications. This means we depend on perceived rather than physical affordance.

Buttons and radio buttons are not the only User Interface (UI) components to make the transition from the physical to digital world (think restaurant menus or the tabs in filing cabinets and telephone organisers), but let's stick with them for now.

Even though digital radio buttons look nothing like their physical counterparts used to, a common visual convention for digital buttons and radio buttons has emerged over the past three decades or so. If you're sighted and you've used any form of Graphical User Interface (GUI) in that time, you'll probably be able to recognise a button or set of radio buttons by their visual appearance. if you can't see and use a screen reader instead, then you'll recognise them based on their semantics and the way your screen reader announces that information.

Mismatch

Which brings us to the mismatch problem.

Using a set of radio buttons for a component that lets people select one thing at a time makes sense - it's what they're for after all. It's when the radio buttons don't look like radio buttons that the mismatch happens.

If you're a sighted mouse user, you'll see a set of buttons and your prior experience will tell you that you can point at the one you want and click on it with the expectation that something will happen when you do - and indeed it does.

If you're a sighted keyboard user, you'll also see a set of buttons, and your prior experience will tell you that you can repeatedly use the Tab key to navigate to the button you want, then the Enter or Space keys to activate it - except you can't because it isn't a set of buttons, it's a set of radio buttons, and the keyboard interaction is not the same.

You can use the Tab key to move to the first radio button in the set, but if you press it again, you'll navigate to the next focusable element after the radio buttons, not to the next radio button in the set. In other words, unless you happen to guess you're really using a set of radio buttons and you realise you should be using the arrow keys not the Tab key to navigate between them, you're likely to think the component is broken because you can't reach any other buttons in the set.

Note: Firefox is the exception because it does allow you to use the Tab key to navigate between all radio buttons in a set.

If you're a sighted screen reader user, you too will see the set of buttons, and your prior experience will tell you that you can use your screen reader's shortcut key for navigating to and between buttons to reach them - except you can't because it isn't a set of buttons, it's a set of radio buttons, and the screen reader shortcut is not the same.

One of the Inclusive Design Principles is:

Be consistent: Use familiar conventions and apply them consistently.

It goes on to explain:

Familiar interfaces borrow from well-established patterns. These should be used consistently within the interface to reinforce their meaning and purpose. This should be applied to functionality, behaviour, editorial, and presentation. You should say the same things in the same way and users should be able to do the same things in the same way.

Good design means following that principle and making sure that the functionality of your component matches the perceived affordances of your visual design, or that your visual design matches the functionality of your component.

<img 
  alt="A baby smiling with a yellow headband."
  srcset="
    baby-s.jpg  300w,
    baby-m.jpg  600w,
    baby-l.jpg  1200w,
    baby-xl.jpg 2000w
  "
  sizes="
    (min-width: 2420px) 2000px, 
    (min-width: 720px) calc(94.76vw - 274px), 
    (min-width: 520px) calc(100vw - 96px), 
    calc(100vw - 32px)
  "
>

You need to create/serve/cache multiple versions of images, know exactly how wide they are, and then accurately put that into the srcset attribute in the HTML syntax. Hopefully, you don’t need to change that system very often if ever.

I find sizes even more difficult, as it needs to accurately describe how wide the image will render at different potential breakpoints in the CSS. Even if you’re intimately familiar with your CSS, it’s mind-bending to figure out. A lot of sites just kinda punt on it with something very vague like sizes="(max-width: 340px) 100vw, 340px", which assumes you’ll be rendering the image at full width if the browser window is smaller than the image; otherwise at the full width of the browser window (rarely true). Plus, CSS changes!

Not trying to crap on the responsive images syntax; it’s just hard. Hard to get right off the bat, hard to automate, and hard to keep right over time.

The irony of the sizes attribute, in particular, is… doesn’t the browser already know how big an image will render at? Well, it does, but only after layout happens. The point of the HTML attribute is that if the information it has is correct, it can make decisions about what image to download before that and be efficient about it (the whole point of responsive images).

But what if the browser doesn’t need to download the image right away, anyway? That’s what happens with <img loading="lazy" ... />, which is certainly a best practice for doing images efficiently. Well if the browser isn’t bothering to download an image until later, then the layout rendering step has already been done, and the browser really does know how big the image is on the page. Thus… sizes doesn’t really matter! In that case, wouldn’t this be nice?

<img 
  alt="A baby smiling with a yellow headband."
  srcset="
    baby-s.jpg  300w,
    baby-m.jpg  600w,
    baby-l.jpg  1200w,
    baby-xl.jpg 2000w
  "
  loading="lazy"
  sizes="auto"
>

Looks like that’s happening and that’s great. I wish I could tell you what browsers it’s landing in and when, but I have no idea. I just like that it has legs.

⚠️ At the time of writing this only work well in Chrome Canary 115+. I cannot fix this for you in other browsers. For browsers that don’t have multi-page View Transitions turned on by default (literally all of them) your pages will load like normal pages. This technique is a ✨ wonderful progressive enhancement.

Let’s get started adding View Transitions to our site…

1. Enable flags in Chrome Canary

To get started with View Transitions, enable them in Chrome Canary.

chrome://flags#view-transition
chrome://flags#view-transition-on-navigation

⚠️ These flags also exist in Chrome Stable and Arc (but not Edge?) but the page will randomly lock up, so stick with Canary or until Chrome Stable hits v115 around Jul 12, 2023. It’s not announced when/if they will unflag this in future releases.

Now we get to the fun part…

2. Include the view-transition meta tag

Add the following to the global <head> of your layout template.

<meta name="view-transition" content="same-origin" />

Congrats, you now have page transitions! This one-liner applies a crossfade effect across your entire site. Your website is now a PowerPoint. It’s unclear to me if the <meta> tag will be the final solution to enable this functionality, but I’m happy to see it works.

3. Add individual element transitions

You’re probably asking yourself two questions:

• How do I create an effect more exciting than a crossfade?
• How do I transition specific elements?

The answer to that is: named view transitions in CSS. Give the element you want to transition from (on page1.html) and element you want to transition to (on page2.html) the same unique view-transition-name. Let’s use a Bootstrap-style “Jumbotron” as an example.

<div class="jumbotron" style="view-transition-name: hero">
  <!-- content goes here -->
	<a href="/product.html">Buy Now</a>
</div>

On product.html find the target element you want your element to morph into and give it the same view-transition-name

<div class="product-header" style="view-transition-name: hero">
  <!-- content goes here -->
</div>

Voilà! This gives you a “morph” effect between the two pages. If you hate the inline styles, this can be done in a CSS file as well.

.jumbotron { view-transition-name: hero }
.product-header { view-transition-name: hero }

And if you want to be a real champ, disable the morph effect for people who get motion sickness. 🏆

@media not (prefers-reduced-motion: reduce) {
	.jumbotron { view-transition-name: hero }
	.product-header { view-transition-name: hero }
}

Before jumping into making our own custom transitions, let’s pause for a minute and look at how this all works and learn about any limitations in the underlying technology…

How does this all work?

Behind the scenes the browser is rasterizing (read: making and image of) the before and after states of the DOM elements you’re transitioning. The browser figures out the differences between those two snapshots and tweens between them similar to Apple Keynote’s “Magic Morph” feature, the liquid metal T-1000 from Terminator 2: Judgement Day, or the 1980s cartoon series Turbo Teen.

If those references are lost on you, how about the popular kids book series Animorphs?

This is exactly how it works and no I won’t be taking any further questions. Anecdotally, it appears to negotiate the X,Y position and the height/width of the before and after states. It will then hot swap your DOM for rasterized images (like transitions), resize transform the height/width, translate the position, and crossfade animation between the old and new states. Basic but convincing.

Unique limitations for lists of many items

Right now MPA view-transitions need to be unique! If you have two elements on the same page with the same transition name (e.g. view-transition-name: post) the browser gets confused and will bail on the view transition, falling back to cross-fade.

Thankfully there’s a workaround if you’re trying to animate from a list-view to a details-view and back by adding a unique view-transition-name in your template. This example is a list of posts:

<div class="posts">
{% foreach post in posts %}
  <a style="view-transition-name: post-{{ post.id }}" href="{{ post.url }}">{{ post.title }}</a>
{% endforeach %}
</div>

This view transition will have the name of post-123 in your rendered HTML. You then add the same “slug” to your post template to morph the link in to the article header.

<article>
  <header style="view-transition-name: post-{{ post.id }}">
    <h1>{{ post.title }}</h1>
  </header>
  ...
</article>

Now you’ve hacked the system and are able to transition as you’d expect. One side effect to be aware of is that this creates a lot of pseudo-elements in your Web Inspector…

<!DOCTYPE html>
<html lang="en-us">
  ::view-transition-group(root)
  ::view-transition-group(post-123)
  ::view-transition-group(post-124)
  ... etc
	::view-transition-image-pair(root)
	::view-transition-image-pair(post-123)
	::view-transition-image-pair(post-124)
	... etc
	::view-transition-old(root)
	::view-transition-old(post-123)
	::view-transition-old(post-124)
  ... etc
	::view-transition-new(root)
	::view-transition-new(post-123)
	::view-transition-new(post-124)
	... etc

I imagine this is fairly moot, but could also be similar to a “too many DOM nodes” performance and debugging issue. You do what you want, but I’m probably going to be conservative about this and avoid applying it on gigantic lists. I’m hoping a better, less manual/explicit API for list-to-detail transitioning comes along, but for now this works.

4. Customize your view transitions

What if the “morph” transition isn’t what you want? You can control your named view transition’s old (outgoing) state and the new (incoming) state using the ::view-transition-old() and ::view-transition-new() pseudo elements.

/* Old stuff going out */
::view-transition-old(hero) {
  animation: fade 0.2s linear forwards;
}

/* New stuff coming in */
::view-transition-new(hero) {
  animation: fade 0.3s linear reverse;
}

@keyframes fade {
  from {
    opacity: 1;
  }
  to {
    opacity: 0;
  }
}

It’s a little duplicative, but nice to have control over the incoming and outgoing content. Small subtle tweaks like making the old content fade out a little faster than the new content comes in can make your app feel uniquely yours.

I mostly use the default morph transition, but ran into a problem on my About section subnav where I didn’t like how the morph transition was scaling my text due to a difference in content container sizes between pages. Adding width: fit-content to the transition worked wonders and I got a quick horizontal resize effect I’ve wanted for a long time.

Sky’s the limit on how far you want to go with this. Get ready for egregious animation wipes coming to a website near you.

Have fun, progressively

I think the most telling predictor for the success of the multi-page View Transitions API – compared to all other proposals and solutions that have come before it – is that I actually implemented this one. Despite animations being my bread and butter for many years, I couldn’t be arsed to even try any of the previous generation of tools.

The ability to easily – with a <meta> tag and a handful of CSS properties – create quality 60 FPS page transitions is a game changer and I look forward to what more creative people will do with this technology. My head is already spinning with ideas. The best part about MPA View Transitions, is that under the hood it’s just normal “dumb” page loads and we’re progressively enhancing our way into smart, sleek transitions all with zero JavaScript required.

I sure hope other browsers hop on board. 👀

We've seen it plenty of times around the web where a website's page header follows us as we scroll down the page. CSS makes doing this a breeze with sticky positioning:

.page-header
 
{

 
position
:
 sticky
;

 
top
:
 0
;

}

What if we desired something a little bit extra, like applying a box-shadow to the sticky header as soon as the page is scrolled? I thought it was worth sharing one solution that has worked well for me to accomplish this goal. Check out the following CodePen demo. As soon as the page is scrolled, a shadow fades in below the header.

See the pen (@hexagoncircle) on CodePen.

An element that I've decidedly dubbed an "intercept"—naming is hard and this felt right in the moment—is created and inserted above the page header at the top of the page. If we open the browser dev tools and inspect the DOM, we'll find:

 
<div data-observer-intercept>
</div>

 
<header id="page-header">
 //...
 </header>

The Intersection Observer API is being used to observe when the intercept is no longer appearing in the visible viewport area which happens as soon as the page scrolls. So when the intercept is not intersecting, a class is applied to the header element.

const
 observer 
=
 
new
 
IntersectionObserver
(
(
[entry]
)
 
=>
 
{

 header
.
classList
.
toggle
(
"active"
,
 
!
entry
.
isIntersecting
)
;

}
)
;
observer.observe(intercept);

Inspecting the DOM again, we'll catch the active class name on the page header element toggling on and off as we scroll down and back up.

Delay that shadow

It's also possible to wait on when the shadow should appear by offsetting the intercept element. Try editing the above demo on CodePen. In the CSS panel add the following ruleset:

[data-observer-intercept]
 
{

 
position
:
 absolute
;

 
top
:
 300px
;

}

This will push the intercept down from the top of the page by 300 pixels. When scrolling the page again, notice that the shadow doesn't appear right away, waiting until the page has been scrolled passed the offset value.

Have questions? Other ways to handle this? I'd love to hear about it! Reach out to me on Mastodon with your ideas.

When I want type hints in VSCode for smaller, personal projects, I use JSDoc which lets you declare types inside plain, old JavaScript comments — you can even share them across files!

// file: file-1.js
/**
 * @typedef Candy
 * @property {string} name
 * @property {"chocolate"|"gummy"} type
 */
 
// file: file-2.js
/** @type { import('./file-1').Candy[] } */
const candy = [
  { name: "Kit Kat", type: "chocolate" },
  { name: "Peach Rings", type: "gummy" },
];

If you’re using VSCode, that means no compiling/transpiling/configuration necessary. Type hints work out of the box.

In addition, sticking @ts-check at the top of the file will give you type checking on code in the file, red squiggles and all.

This is great because it gives me type hints and checks as I code. But sometimes I also want the benefits of my types at runtime. JSDoc won’t give me that. Not even Typescript will give me that, as it only works up to compile time.

For runtime, you need something like Zod, which lets you write your type schemas, then infer them as Typescript types automatically.

// Declare your schema with zod
const CandySchema = z.object({
  name: z.string(),
  type: z.enum(["chocolate", "gummy"]),
});

// Extract the type for typescript
type Candy = z.infer<typeof CandySchema>;

// Instead of re-writing it like this
type Candy = {
  name: string;
  type: "chocolate" | "gummmy";
};

But what if you don’t want to write .ts files? What if you’re writing regular old .js files with JSDoc comments? Can you infer your Zod types in JSDoc?

It appears^[1] you can!

// Declare your schema with zod
const CandySchema = z.object({
  name: z.string(),
  type: z.enum(["chocolate", "gummy"]),
});

// Extract the inferred type as a JSDoc type
/** @typedef { z.infer<typeof CandySchema> Candy } */

// Instead of re-writing it as a JSDoc type like this
/**
 * @typedef Candy
 * @property {string} name
 * @property {"chocolate"|"gummy"} type
 */

With this approach, you “declare your types” with Zod in regular JavaScript files and then you can 1) use them at runtime and 2) extract them as JSDoc types and use them as hints in your editor.

// file: file-1.js
const CandySchema = z.object({
  name: z.string(),
  type: z.enum(["chocolate", "gummy"]),
});
/** @typedef { z.infer<typeof CandySchema> Candy } */

// file: file-2.js
/** @type { import('./file-1').Candy[] } */
const candy = [
  { name: "Kit Kat", type: "chocolate" },
  { name: "Peach Rings", type: "gummy" },
];

A @ts-check at the top of the file gives you red squiggles type checking in the file too — no .ts files required!

Again, the beauty of this approach is that it’s all JavaScript. You don’t have to compile/transpile/configure anything. The code you write is 100% valid JavaScript you can dump straight into the browser, but it also provides you a nice DX in VSCode as you program.

In my particular case, I use this on a SSG project where I want to 1) ensure the data flowing through my site generator is correct by using runtime (i.e. build time) type checking, and 2) get nice hints directly in my editor as to the shape of my data as well as in-file squiggles for any errors.

It’s just enough to help me be productive without requiring I setup and maintain Typescript tooling over time.

1. It was harder than I thought to find out about JSDoc + Zod online, but thanks to this gist I was able to figure it out. So, I figured I’d write a quick blog post in case anyone in the future ever wants to know if you can infer types using Zod with JSDoc comments in plain JavaScript files. ↩

• Reply via: Email, Twitter, Mastodon

This will retread and extend on my previous Inclusively Hidden post. Specifically the parts about “visually hidden” content.

But in lieu of reading that, the reasons one would visually hide content in the development of a website or web application is generally to include extra content for accessibility. For instance, to mitigate against specific design choices, where visually something may be apparent, but programmatically not so much. Or, portions of UI are only need to be visible when needed, but otherwise they need to be hidden but remain accessible so that those using keyboard or assistive technology can find them.

The way to visually hide content, but keep it programmatically available, that is probably the most familiar to many developers is with the following CSS ruleset, or a variation of it:

/* sometimes referred to as .sr-only */
.visually-hidden:not(:focus):not(:active):not(:focus-within) {
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap; 
  width: 1px;
}

For a breakdown of what each CSS property is doing, check out this dissection of the ruleset, by TPGi. Tbh, depending on your browser support matrix, I’ve found that there a few property declarations that can be removed with no negative impact for modern browsers/screen readers. Just something to think about. Maybe test this out n’ see if you can find something broken? Not endorsing this method, but also, presently unaware of issues - so long as you’re using this to visually hide static content. As in, this ruleset not intended to hide interactive controls. But just static content within an interactive control.

At the end of that TPGi article, the idea of consolidating this ruleset into a single CSS declaration, for example display: visually-hidden, was mentioned. This idea was also a brought up in “The Web Needs a Native .visually-hidden”, by Ben Myers. But this is not a new topic, and has been brought up over the years. For instance, as a request for an HTML feature, and as different CSS WG issues from 2016.

Full disclosure, I have frequently used and recommended the use of visually hidden content. It’s an important tool that we presently need to help mitigate accessibility gaps for content (design) and features of and related to common web UI. However, while a frequent recommendation, it’s one I would rather I never had to mention again. But, before we get into that, and why I find the idea of the technique becoming any sort of web ‘standard’ rather icky, let’s review some situations where this ruleset is commonly used.

Examples of visually hiding content

Often, one will need a skip to main content link on their website or web application in order to adhere to WCAG’s 2.4.1 Bypass Block. The most common way of implementing this instance of a skip link is to visually hide it until it receives keyboard focus. Because a skip link is a navigational mechanism for a sighted keyboard user, after all. So one needs to be able to see what they’ve focused to know whether or not to try and interact with it.

Not all news websites have a skip to main content link, but NPR.org does. They have a couple which become visible when they receives keyboard focus.

NPR uses a variation of the visually hidden class.

Or, one might visually hide pesky form controls so that they are still available to screen reader and keyboard users. But maybe you wanted to replace them with a fancy ‘custom’ control(s), allowing for more styling options.

Visually styled to look like stars and a cancel icon, these are all native HTML radio buttons and would be exposed as such if styles were turned off or blocked.

Fun fact, these radio buttons don't use the 'typical' visually hidden class.

Alternatively, maybe you don’t need to restyle a control, but only want it available on hover and focus. That’s a thing we do to make it more difficult for sighted touch, switch device and speech recognition users to find initially hidden controls. I mean, to visually declutter UI.

But snark aside, there is a constant push and pull between overloading UI with too many controls or too much content. If the UI has too many competing visual features at one time, it can be overwhelming for some users. However, hiding important UI can result in higher difficulty for other users to interact with the page. The struggle is real.

Each line of code can be commented on with a GitHub pull request. It would be overwhelmingly redundant to visually have a comment button on each line, so it is visually hidden until the line is hovered, or the button receives keyboard focus.

These buttons also don't use the typical visually hidden class.

Or or, content might need to be visually hidden because someone wrote some rubbish call-to-action copy and the web page would otherwise be riddled with “learn more” or “read more” links that have no immediate programmatic context to their purpose.

Maybe a web app was designed in a way where one can infer the current page’s purpose due to the styling of the “current page link” in the primary nav - so there’s no visible heading to introduce the primary content of the page. Oh, and adding that heading in there would “degrade the design”, so cool. Guess we can insert a visually hidden heading to help screen reader users, at least, without disrupting the design which would be absolutely ruined and unusable if a heading was added. Horrible, horrible headings…

Rather than display the primary heading of the page, Facebook visually hides it.

The visually hidden technique appears to be used here, but has been obfuscated into various single-purpose compiled classes. .x1heor9g is a real banger of a utility class, if I do say so myself.

Or or or, a website or web application requires a ‘global’ live region component. For instance, rather than having multiple live regions on a web page, a single live region is used to expose dynamic updates to a page. Live regions can be quite annoying to get right, so a persistent visually hidden live region is often used for complex web apps, so as to work around having to have tons of empty live regions in a screen, waiting for content to be added to them so they can inform screen reader users that “You must fill out your name. It is REQUIRED!!!! SURE I KNOW YOU’RE JUST TABBING THROUGH THE PAGE RIGHT NOW TO CHECK OUT WHAT THIS FORM INCLUDES, BUT DAMNIT I NEED YOUR NAME! I NEED IT NOW!!!! NOW!!!!!” I may have some thoughts about how aggressive web forms are with on-blur error messaging.

The most on the nose instance of the .sr-only class, being used to visually hide a global ARIA live region as the last element in a web page.

There are other instances of where you may want content to be hidden but available only for people using assistive technology, or only when the hidden content is actually relevant (e.g., a sub-navigation list of links). These would be different from the previously mentioned examples, as these would not be situations where the content should be treated as visually hidden. Rather, they would generally need to be hidden to everyone. Again, see my previous blog post for more information on stuff like that.

Sure does seem we need to visually hide stuff quite a bit?

If there’s a need for so many instances of visually hidden content, why wouldn’t it be standardized? Well, I mean standardized beyond the already existing ways to visually hide content:

• color: transparent
• opacity: 0
• transform: scale(0)
• clip-path: inset(50%)
• etc.

By themselves, each of these properties be used to visually hide content per the situation, but someone might have to add a few extra property declarations, e.g., position: absolute, to get the content to no longer take up visual space in the document layout. Or, a combination of some of the above or other properties may be necessary to fit one’s exact visually-hidden needs. For instance, if creating a custom checkbox style, one might think to just use the standard visually hidden class.

However, as I've been noting for some time now and others have since mentioned, using the standard visually hidden class will introduce problems due to the 1px by 1px nature of the beast/ruleset.

Remember, not all screen reader users are completely blind. Some of these users, for instance, might be able to see or partially see a custom checkbox on their iOS or Android device. They might then think to press or drag their finger across their screen to “explore by touch” while the screen reader is enabled, only to then be seemingly unable find this checkbox that visually appears to be there, but is really shoved off into a 1px by 1px square somewhere on the page. Fun!

Heck, this problem would exist even for instances of not completely restyling a checkbox from the ground up (which also, unless you're going way out there with a custom style, we don't really need to do anymore.

Consider a button (such as a “more options”, or “edit”, “delete”, etc.) that is visually hidden in a ‘card’ or ‘row’ of content, where it only becomes visible on hover (generally of the whole container), or focus/focus-within the container. If the standard visually hidden class was used here, this too would suffer from the 1px by 1px problem. (You may remember I mentioned GitHub has a visually hidden comment button for reviewing PRs, but it doesn’t use the standard visually hidden technique. They don’t have this 1px by 1px problem!)

A standardization of the ruleset wouldn’t help with these situations. Actually, it’d probably make the problem more prevalent, since many developers would (understandably) think all they needed to do was to set this fabled single property, and all their accessibility problems concerning content that needed to be hidden would go away. Just like ARIA, it’s there to make your content more accessible.

Wait… what? ARIA gets used in situations where it is either unnecessary or not appropriate for the use case? Shocking.

What about fixing the underlying problems instead?

Getting caught up in how to make visually hiding content easier for developers to implement (you know, so they don’t have to copy/paste a class name), imo, is missing the mark on solving the real issue. We “need” to visually hide content because of gaps in the design of the UI, or because of features which are lacking from browsers.

For many of the examples called out earlier, what if those gaps were solved instead?

Skip to content links are also a dirty hack

We shouldn’t need skip to content links. Rather, what would be way more useful that including a visually hidden link at the top of every website, is if browsers would support navigation by elements that are exposed as landmark roles. At the very least, allow for a mechanism to directly move focus to the content of the main element/landmark. Alternatively, allowing for quick navigation by headings would be pretty awesome, too.

Implementing one of those ideas could negate the need for skip to main content links, at least. You don’t need to visually hide something that isn’t necessary to implement, after all.

Styling form controls isn’t as bad as it used to be

Yes, visually hiding a form control so that a custom styled ‘faux’ control can be rendered in its place is rather common. But as mentioned, the standard visually hidden ruleset is not what you should be using to effectively hide the few controls that even allow for this hack. Also, wouldn’t it be far better if time was instead spent trying to push proposals like a new checkbox element over the line?

IMO, new checkbox and radio elements are not the most important features we need on the web. But if given the option between those and a standardized visually hidden feature, yes. Please. New checkboxes and radios. Solve for the problem, not the symptom.

Regarding aria-label and insufficient CTAs

A web page containing a bunch of buttons or links with, for example, “edit” or “learn more” visible text, and thus accessible names, can be rather rubbish depending on the way one is navigating the web page.

For instance, a page listing article or product previews, each with with a “learn more” call to action link. Without extra development effort, all these links will simply be exposed as “learn more” when someone navigates by focusable elements, or uses their screen reader to navigable specifically by links.

Code for what could produce the above link listing might look something like this:

<div class="card-or-whatever">
  <h3>Here's some descriptive text but lol, I'm not a link!</h3>
  <p>Fluffy fluff fluff tells you stuff about the fluff.</p>
  <p><a href=...>Learn more!</a></p>
</div>

In these contexts where the link serves as a standalone CTA outro to UI elements like ‘cards’, these can be flagged as 2.4.4 Link Purpose (In Context) failures. This is because the CTA is not programmatically associated with other text (e.g., a paragraph) to help provide the context as to what one would be learning more about.

This is why such CTAs are commonly recommended to use the visually-hidden technique to provide more context. For instance,

<a href=...>
  Learn more
  <span class=visually-hidden>about whatever yada yada</span>
</a>

However, while often used to alleviate this lack of context, there are other avenues we could be considering, instead.

For example, aria-label and aria-labelledby can allow for the same context to be provided, without the need for the visually hidden hack.

<a href="..." aria-label="Learn more about something">
  Learn more
</a>

...

<p id=thing>My address, or whatever</p>
...
<button id=self aria-labelledby="self thing">
  Edit
</button>

Granted, right now translation services and aria-label continue to have issues, and using aria-labelldby has the problem that it necessitates the use of IDs, and developers hate IDs.

So, maybe ARIA isn’t an option for you. But you know what that leaves? Making a better design.

For instance, I’ve already referenced the Nielsen Group article “Learn More” Links: You Can Do Better, but I will do so again because it is worth repeating.

Take a look at many popular news aggregate websites (well, look at them just in the context of this train of thought… I can’t endorse them otherwise, unless you’re looking to significantly up your anxiety and tank your mood. News sites do that great.). Many of which I’ve reviewed show they’ve since moved away from the “learn/read more” CTA approach and instead treat the concise but descriptive titles/headings of their article previews as the links to their content.

“But Scott, user testing has shown that CTAs get more clicks”

Well sure, I didn’t think we needed a test to determine if someone sees a big button-looking control that screams “click me”, they will click it. But visual cues to visually promote “click me” behaviors don’t “need” to impact the accessibility of the content.

For instance, there’s no reason one couldn’t implement a CTA as more of a decorative element that still allowed for pointer events to activate it. A very quick example (and one of the demos even still has the lovely ‘read more’ appear on hover/focus):

See the Pen simple cta article 'card' by Scott (@scottohara) on CodePen.

I’m sure many could come up with more creative designs than that five minute codepen. But maybe take this as a challenge. Accessible design doesn’t need to be boring, rather good accessible design demands creativity. So, be creative and move away from the uninspiring learn more links and visually hidden hack.

We need a notification API

Live regions are finicky, and having to implement a visually hidden live region to act as a notification center for a website/web application is yet another hack built atop a shouty house of cards.

Rather, if we had a notification API, we wouldn’t need to visually hide live regions at all. Rather, we would be able to dynamically render the content we want on our web pages, and then use the API to ensure the rendered text content, or maybe even something more concise/informative than what is visually rendered, could be exposed to the accessibility tree. No reliance on DOM elements, no problems where the live region that should have handled this is within an inert or aria-hidden=true subtree because a modal dialog opened and blew your aforementioned shouty house of cards down.

<dialog>
  Imma be a modal dialog!

  <button>
  	Press me and make a toast show up,
  	but LOL don't expect to hear it!
  </button>
</dialog>

...

<div class=visually-hidden aria-live=polite>
  Inject whatever you want into me, and I'll typically
  announce it. But, I'm not saying 
  "boo" if that modal dialog is open! 
</div>

You want to get around this? Either don’t use the native dialog element (which would be quite a shame, as using it responsibly can be far better than creating your own). Or, put another live region into your dialog, so your page can continue to shout things while the modal dialog is open and everything outside of it is treated as inert.

Wrapping up

For better and worse, we will have instances where we need to visually hide content to mitigage a gap in the visual design. That’s not to say that every gap is necessarily due to a failure to incorporate accessibility in the design process. Rather, because there is a balance that needs to be maintained between what is visually presented, vs what is programmatically conveyed, sometimes the best way to work around that is to inject content that is specifically for people using assistive technology.

Them’s the breaks.

But, as I’ve hopefully illustrated by now, while there is a common ruleset for visually hiding content, codifying that to me seems more of a silent acknowledgement that a hack is the best we can do. I don’t agree. The web should be better than that.

• We should be able to navigate to landmarks (e.g., skip to main content) by default browser commands.
• We should be able to send dynamic messages to assistive technology, without having to rely on fragile, invisible, live regions.
• We should be able to use aria-label (and also aria-description) without having to worry about translation services.
• We should be able to fully and easily style common form controls.
• And we shouldn’t need to introduce a native way to do all these things, which covers various use cases for visually hidden content, but not all of them.

Introducing a native mechanism to save developers the trouble of having to use a wildly available CSS ruleset doesn’t solve any of those underlying issues. It just further pushes them under the rug. Additionally, it introduces an “official” way to hide content which at best, might not be the right way to hide content for a particular use case. And at worse, it provides a hiding mechanism for people to misuse. Content that should be hidden to everyone could get the “well, isn’t it more accessible if we never truly hide content, so that screen reader users can always have access to everything at all times?”

No. That’d be quite problematic. And while paraphrased, that is a question I’ve been asked, when having to mention to someone that they’ve incorrectly hidden content. While this thinking comes from a good place, it is exactly what we don’t want to happen.

Now, one might say that education and examples are the ways to promote correct usage. And that person would be right. But also, if documentation and providing official examples would mitigate misuse and misunderstandings, then we wouldn’t need stack overflow or slack channels for people to post questions, daily, or online courses to explain to developers what existing free resources already cover.

Anyway, that’s it. Those are my very not-hidden thoughts on the topic. Thanks for reading all these yucky words. So so many words…

Before the :focus-visible CSS pseudo-class was introduced, there was no middle ground to this debate - you either sided with design or accessibility (hopefully the latter). But now, with :focus-visible, we can have focus styles that apply only when the browser / user agent determines that focus should be indicated on the element.

So, when do user agents determine that focus should be indicated? According to the :focus-visible specification, user agents are free to choose their own heuristics for indicating focus. However, the spec includes some suggestions, which most browsers have adopted. These suggestions can be broken down into four questions -

1. Has the user expressed a preference for always visible focus?
2. Does the focused element support keyboard input?
3. Is the user interacting with the focused element with a non-pointing device?
4. Did a script cause focus to move from a previously visibly-focused element?

Let’s break each of these questions down.

1. Has the user expressed a preference for always visible focus? #

This is a simple one. If a user has expressed a preference for focus to always be visible, then the :focus-visible pseudo-class should apply to the focused element. Fin.

2. Does the focused element support keyboard input? #

If the focused element supports keyboard input, the :focus-visible pseudo-class should apply. Elements that support keyboard input are typically form elements, such as <input> or <textarea>, basically any element that would trigger a virtual keyboard to be shown in the absence of a physical one.

In the example below, we have both a <button> and an <input>. For the <button>, whether the :focus or :focus-visible style is applied depends on how you interact with the element (more on that in the next section). But regardless of how you interact with the <input> element, it always displays both the :focus style and the :focus-visible style of the red border.

See the Pen Untitled by Ire Aderinokun (@ire) on CodePen.

3. Is the user interacting with the focused element with a non-pointing device? #

Next, if the user is interacting with the focused element using a keyboard or another non-pointing device, the :focus-visible pseudo-class should apply. So regardless of the type of element it is, focus should be visible.

In the example below, the <button> elements display the :focus and/or :focus-visible styles depending on what device you use to interact with it.

See the Pen :focus-visible - Is the user interacting with a non-pointing device? by Ire Aderinokun (@ire) on CodePen.

4. Did a script cause focus to move from a previously visibly-focused element? #

Finally, this question is to do with what happens if focus is moved via a script instead of user input. According to this guideline, the :focus-visible pseudo-class should apply based on the state of the previously focused element. If :focus-visible applied to the previously focused element, then it should also apply to the currently focused element.

We can see this play out in the example below. Depending on how you interact with the “reset” button, the :focus and/or :focus-visible styles will apply to the test button when focus is programatically moved.

See the Pen :focus-visible - script by Ire Aderinokun (@ire) on CodePen.

Bonus - User agent wildcard #

As a reminder, these are mostly guidelines/suggestions and user agents are still able to make decisions about when they want :focus-visible to apply. From my tests, I haven’t seen any of the major browsers respond in a different way, but it’s something to remember.

Because of this, best practice is always to only remove :focus styles if :focus-visible is not also applied to the element. Here’s what that looks like:

/* Apply focus styles */
:focus-visible, :focus {
  outline: 1px solid red;
}

/* Remove the focus outline */
:focus:not(:focus-visible) {
  outline: none;
}

I didn’t. But then I watched “A Hipster History of CORS” and the speaker, Devdatta Akhawe, references the history of the feature as outlined in the book JavaScript: The Definitive Guide.

Security in JavaScript in those early days was WDD: whack-a-mole driven development. Find a mole (security hole) and whack it (plug it). From the book:

The approach to JavaScript security in Navigator 2.0 and 3.0 has been to first identify security holes through which private information could be exported, and then to plug those holes…The problem with an identify-and-patch approach is that it can be difficult to identify security holes, and that there is no way of knowing when you've found all possible holes

A conundrum indeed. If you patch security holes as you find them, how will you ever know if you’ve plugged all the holes?

Well that’s easy, my friend. Just get rid of what’s causing the holes.

These security fixes were known as “hobbles” and Netscape came up with the “ultimate hobble”: disable JavaScript.

If you read that chapter, some of the early documented security holes are pretty wild, like this one:

[people used] the file:/// URL to discover the contents of the root directory of the client's system, and could recursively proceed to determine the client's entire directory structure

Of course, if you use node, this particular exploit is still feasible by merely running npm i and having a malicious package somewhere deep in your dependencies — but I digress.

Turning off JavaScript is nice and all, but having JavaScript on is also nice. So “Disable JavaScript” as a feature wasn’t a permanent solution.

Eventually they came up with an idea that would hobble an entire class of security holes: cross-origin restrictions on JavaScript window APIs.

Because of the continuing problem with security holes, and because of the resulting bad press, Netscape soon released Navigator 2.0.2, which fixed all known security-related bugs and implemented a very general hobble that would, hopefully, spell an end to security holes. With this hobble implemented, a JavaScript program is not allowed to read the properties of any window (or frame) or the properties of any objects within a window if the contents of that window were loaded from a different web server than the JavaScript program itself.

This hobble birthed the idea of cross-origin restrictions and eventually made it into XmlHTTPRequest and later everything CORS.

It’s all a fascinating history. Go listen to the talk if this sounds like your cup of tea.

• Reply via: Email, Twitter, Mastodon

On the screen was a grey’ish looking website. Bryan made websites. I made websites. We had that in common. And playing guitar. He looked me in the eyes and said “This is Flex. It’s the future of websites and you need to learn it.” And from what he was showing me, I was impressed and astounded. A fully rich internet application. XML-powered tables and lists with sorting and animations that you’d spend months building in Flash. I had never seen anything this professional before.

Flex was the successor to Flash. Or a better way to put it, Flex was Flash but for applications. It came stock with an entire UI kit (aka design system) with form inputs, textareas, form validation patterns, buttons, tabs, accordions, tree browsers, scrollbars, loading bars, and even a calendar. A UI kit in a box. Everything you needed for serious enterprise-grade business applications.

And when I mean applications, I mean applications. Flex worked with Adobe AIR, so you could install your Flex app on people’s computers in a distributable “native” application. The one true write once, run anywhere framework.

The demo-of-all-demos for Flex had to be the drill-down pie chart on the budgeting app Mint. I would spend hours zooming in my categorized spending to get breakdowns by subcategory and back out. Smooth buttery transitions and animations without a single page load. Mint go acquired by Intuit, so Flex appears to be a kingmaker. YouTube wouldn’t exist without Flash either. Flash and Flex were so popular, Microsoft wrote a competing rich internet application development framework called Silverlight.

Flex had meta-frameworks too to help people build Flex sites even faster. They embraced the super popular MVC pattern. Frameworks make sites better because developers can work faster and that trickles down to the user. Flex and Flash tooling is superior, so you’re able to make experiences you could never dream of making in an HTML5 website.

That’s Flex. It’s built for real applications, not websites. It has a thriving ecosystem. Backed by a big company like Adobe. Regular updates. It’s built on Flash and used by the majority of serious web developers. It’s great, no problems.

Okay. I’ll admit making Flash sites accessible is notoriously difficult. And SEO for Flash sites is also difficult. But beyond that, perfect.

Okay, okay. If you want to be a little more critical… one problem with Flex applications is that they don’t work well on phones. They only worked on one phone to be exact; the Motorola Droid. My brother had one of those phones. He could play tower defense Flash games on it. He made a lot more Flash websites than I did (I got into custom faux-Rails PHP sites), so it made sense why he liked the non-censored version of the web.

Steve Jobs didn’t have to write a mean blog post about Flash. A lot of people make a living doing Flash sites, so that’s pretty rude of him. Who cares if Flash was extremely impractical for phones because it shredded the battery and had a bunch of security holes. Flash was popular and people liked it and people got paid to make Flash and Flex sites, ergo, it’s good. But it didn’t matter if Steve didn’t like Flash because the majority of my users were on desktop.

Over the years I tried again and again to pick up Flex. I had okay ActionScript skills but the nuances of Flex applications escaped me. Every site I made back then had Flash; band sites, church sites, Homestar Runner clones, zoomy portfolios, and even real estate websites. But it felt like whenever I tried to learn Flex for serious web applications, it had changed enough that I spent all my energy relearning the basics and I could never get to the interesting parts, like the drill-down pie chart I loved so much.

Eventually I read Jeffrey Zeldman’s book and settled on making boring websites that anyone could use. Flex and Flash meanwhile died slow deaths because Steve was a meanie. As time marched on, whenever you ended up on a Flex site you could tell. It wasn’t the loading bars, but the buttons and UI that felt frozen in time. They weren’t nearly as fluid and fast as the new-fangled Script.aculo.us-powered sites.

I was real happy when CSS animations came to Webkit, the browser I had on my Steve Jobs phone, because it meant I could animate and tween again. What a joy!

As for Bryan, he moved away to a farm in Washington and I think he makes boring websites now too. I imagine he’s still the same guy, out there on that farm summoning infinite stamina to stay awake for five days straight to finish his projects. He may have been wrong about Flex, but he was good at guitar.

Default ARIA for Custom Elements

To use ElementInternals with a custom element, call this.attachInternals() in a custom element constructor just the same way we’d call attachShadow() as follows:

class SomeButtonElement extends HTMLElement {
    #internals;
    #shadowRoot;
    constructor()
    {
        super();
        this.#internals = this.attachInternals();
        this.#internals.ariaRole = 'button';
        this.#shadowRoot = this.attachShadow({mode: 'closed'});
        this.#shadowRoot.innerHTML = '<slot></slot>';
    }
}
customElements.define('some-button', SomeButtonElement);

Here, #internals and #shadowRoot are private member fields. The above code will define a simple custom element whose ARIA role is button by default. Achieving the same effect without using ElementInternals required sprouting ARIA content attribute on the custom element itself like this:

class SomeButtonElement extends HTMLElement {
    #shadowRoot;
    constructor()
    {
        super();
        this.#shadowRoot = this.attachShadow({mode: 'closed'});
        this.#shadowRoot.innerHTML = '<slot></slot>';
        this.setAttribute('role', 'button');
    }
}
customElements.define('some-button', SomeButtonElement);

This code is problematic for a few reasons. For one, it’s surprising for an element to automatically add content attributes on itself since no built-in element does this. But more importantly, the above code prevents users of this custom element to override ARIA role like this because the constructor will override the role content attribute upon upgrades:

<some-button role="switch"></some-button>

Using ElementInternals’s ariaRole property as done above, this example works seamlessly. ElementInternals similarly allows specifying the default values of other ARIA features such as ARIA label.

Participating in Form Submission

ElementInternals also adds the capability for custom elements to participate in a form submission. To use this feature of custom elements, we must declare that a custom element is associated with forms as follows:

class SomeButtonElement extends HTMLElement {
    static formAssociated = true;
    static observedAttributes = ['value'];
    #internals;
    constructor()
    {
        super();
        this.#internals = this.attachInternals();
        this.#internals.ariaRole = 'button';
    }
    attributeChangedCallback(name, oldValue, newValue)
    {
        this.#internals.setFormValue(newValue);
    }
}
customElements.define('some-button', SomeButtonElement);

With the above definition of a some-button element, some-button will submit the value of the value attribute specified on the element for the name attribute specified on the same element. E.g., if we had a markup like <some-element name="some-key" value="some-value"></some-element>, we would submit some-key=``some-value.

Participating in Form Validation

Likewise, ElementInternals adds the capability for custom elements to participate in form validation. In the following example, some-text-field is designed to require a minimum of two characters in the input element inside its shadow tree. When there are less than two characters, it reports a validation error to the user using the browser’s native UI using setValidity() and reportValidity():

class SomeTextFieldElement extends HTMLElement {
    static formAssociated = true;
    #internals;
    #shadowRoot;
    constructor()
    {
        super();
        this.#internals = this.attachInternals();
        this.#shadowRoot = this.attachShadow({mode: 'closed', delegatesFocus: true});
        this.#shadowRoot.innerHTML = '<input autofocus>';
        const input = this.#shadowRoot.firstChild;
        input.addEventListener('change', () => {
            this.#internals.setFormValue(input.value);
            this.updateValidity(input.value);
        });
    }
    updateValidity(newValue)
    {
        if (newValue.length >= 2) {
            this.#internals.setValidity({ });
            return;
        }
        this.#internals.setValidity({tooShort: true}, 
            'value is too short', this.#shadowRoot.firstChild);
        this.#internals.reportValidity();
    }
}
customElements.define('some-text-field', SomeTextFieldElement);

With this setup, :invalid pseudo class will automatically apply to the element when the number of characters user typed is less than 2.

Form-Associated Custom Element Callbacks

In addition, form-associated custom elements provide the following set of new custom element reaction callbacks:

• formAssociatedCallback(form) – Called when the associated form element changes to form. ElementInternals.form returns the associated from element.
• formResetCallback() – Called when the form is being reset. (e.g. user pressed input[type=reset] button). Custom element should clear whatever value set by the user.
• formDisabledCallback(isDisabled) – Called when the disabled state of the element changes.
• formStateRestoreCallback(state, reason) – Called when the browser is trying to restore element’s state to state in which case reason is “restore”, or when the browser is trying to fulfill autofill on behalf of user in which case reason is “autocomplete”. In the case of “restore”, state is a string, File, or FormData object previously set as the second argument to setFormValue.

Let’s take a look at formStateRestoreCallback as an example. In the following example, we store input.value as state whenever the value of input element inside the shadow tree changes (second argument to setFormValue). When the user navigates away to some other page and comes back to this page, browser can restore this state via formStateRestoreCallback. Note that WebKit currently has a limitation that only string can be used for the state, and “autocomplete” is not supported yet.

class SomeTextFieldElement extends HTMLElement {
    static formAssociated = true;
    #internals;
    #shadowRoot;
    constructor()
    {
        super();
        this.#internals = this.attachInternals();
        this.#shadowRoot = this.attachShadow({mode: 'closed', delegatesFocus: true});
        this.#shadowRoot.innerHTML = '<input autofocus>';
        const input = this.#shadowRoot.querySelector('input');
        input.addEventListener('change', () => {
            this.#internals.setFormValue(input.value, input.value);
        });
    }
    formStateRestoreCallback(state, reason)
    {
        this.#shadowRoot.querySelector('input').value = state;
    }
}
customElements.define('some-text-field', SomeTextFieldElement);

In summary, ElementInternals and form-associated custom elements provide an exciting new way of writing reusable component that participates in form submission and validation. ElementInternals also provides the ability to specify the default value of ARIA role and other ARIA properties for a custom element. We’re excited to bring these features together to web developers.

So when he tagged me on Mastodon asking about an AVIF/iOS bug — which I was not familiar with — I was super intrigued. Here’s Tyler:

iOS 16 added support avif images, but seems like there could be bugs? Seeing support for the image/avif image type, so avif version loads, but then displays as a broken image. https://tests.caniuse.com/avif

What could it be?

I went down a rabbit hole of image optimization a while back, trying to decide if I should support newer image formats on my icon gallery sites. The one takeaway I remember was this: AVIF seemed incredibly promising in its capability to preserve quality while drastically decreasing file size. However, browser support at the time was not great.

Fast-forward to 2023 and I still haven’t seriously considered revisiting AVIF, though I know support has been broadening.

So hearing what Tyler had to say about his own mileage with AVIF piqued my interest. In general, I like to let other people smarter than me bleed on the edge. Then I catch the second wave and learn from all their cuts and bruises.

Thankfully, Tyler blogged about what he found out. What struck me most in his post was how proper he served his images yet still had a nasty bug.

I've been using AVIF images throughout this site since about 2020. I use the source element with srcset to provide AVIF, WEBP, and JPG or PNG formats for most images. This worked until iOS shipped support for AVIF. Before then, iOS would just not recognize the AVIF format and use WEBP instead.

With AVIF support, iOS started recognizing and loading AVIF images…[but] there would be a missing image. Either blank, in Chrome iOS, or the little blue question mark in Safari iOS.

It seems like he did all the right things: multiple image formats (old and new) with semantic markup allowing the client to choose the best supported experience. Yet he still had issues — on a modern browser nonetheless.

The beautiful theory of new image formats like AVIF is that you can leverage HTML to provide a baseline experience that works across the most clients possible (using an old format like PNG) and then, for clients that support it, provide additional markup for the new fancy formats of the present, like WEBP or AVIF.

<picture>
  <source type="image/avif" srcset="…" />
  <source type="image/webp" srcset="…" />
  <img src="….png" srcset="…" alt="…" />
</picture>

In this way, modern clients that support a new format like AVIF can fetch those resources and ignore the others while older browsers will just fetch the PNG image.

In Tyler’s case, he did everything right but the modern clients were still failing. They were looking at the HTML and saying, “Oh yeah, we support AVIF. Let’s fetch that!” But then the AVIF images were failing to render in the browser.

Why? Here’s Tyler:

TL;DR: [You’ll have to] re-encode any AVIF images that aren't working. There have been AVIF spec changes and there were bugs in popular encoders that caused AVIF not to work in iOS.

I was a little surprised when I first saw this was the problem. I joked that, “images are software now. you have to update (e.g. re-encode) between major versions or things break.”

But in all seriousness, there’s a good reminder in Tyler’s experience for me.

To keep things from breaking on the web, the idea is to build with new technologies (e.g. client APIs or image formats) by layering experiences on top of each other. Start with a baseline and enhance. If you build this way, you can watch support become more ubiquitous and not have to change a thing (or at least very little).

However, as Tyler’s example shows, just because you layer in a new technology doesn’t mean it’ll work for any browser that adopts support for it. Burgeoning technologies change constantly and even layered experiences can break. Not because the experience isn’t supported. On the contrary, it very well might be supported, just in an earlier, non-compatible form.

Resiliency is important, but it’s not being bullet proof. Nothing’s bullet proof, even with modern clients.

• Reply via: Email, Twitter, Mastodon

import CryptoJS from 'crypto-js'

const encryptedThing = CryptoJS.AES.encrypt("message", SECRET_KEY).toString()
const decryptedThing = CryptoJS.AES.decrypt(encryptedThing, SECRET_KEY).toString(CryptoJS.enc.Utf8)

It’s an AES cipher block that puts a message in a cipher, and decrypts it on the other end. Cool. It uses math, like popular cryptographic technology Bitcoin, so you know it’s good.

As I was ready to push the code up, my tests were failing in the prepush hook. I knew the code was working but I’d have to appease Jest. Jest’s issue was it didn’t know about the import CryptoJS from 'crypto-js' part because it only understands require(). I’ve dealt with this problem before. I had some other module mocks in that file, so I copied them verbatim.

// This didn't work.
const mockAESInstance = {
	decrypt: jest.fn().mockReturnThis(),
}

jest.mock('crypto-js', () => {
	return {
		AES: jest.fn(() => mockAESInstance)
		...
	}
})

It didn’t work. Jest kept saying decrypt is not a function. I’ve also dealt with this problem before. So I tried…

• decrypt: jest.fn() - surely this is a function? nope.
• decrypt: jest.fn().mockReturnValue('decryptedThing') = also not a function
• And then I tried every combination based on every amalgamation of every StackOverflow answer I could find to mock a nested object function.

…and it still didn’t work.

I used VS Code’s Intellisense to dig into the types inside CryptoJS. CryptoJS’s AES.decrypt returns a custom type called a WordArray that has a toString() method. Ah ha! Foolish me to think toString() was the native Array.toString() function! I tried mocking the toString() and CryptoJS.enc.Utf8 in a variety of ways but couldn’t get Jest to mock a nested function of a nested object function…

Fuck it, just use Copilot

It was now 10pm. There was dinner. There was watching TV with the kids. There was bed time. But I was noodling on my laptop like a deadbeat dad because I needed Jest to allow this one line of code in my commit. In desperation, I deleted all my attempts and sent a prayer to the AI gods (who were unhelpful up to this point) and kept hitting tab… Copilot summoned this:

// Final Fix 
jest.mock('crypto-js', () => {
	return {
		AES: {
			decrypt: jest.fn().mockReturnValue({
				toString: jest.fn().mockReturnValue('decryptedThing')
			})
		}
		...
	}
})

And it worked! Looking at the final answer, I can see how this appeases Jest, but I ashamedly admit that I would have never got there on my own. A double fn().mockReturnValue(). This situation is an embodiment of my biggest frustration with Jest. The ESM imports thing is big and makes me want to switch to Vitest today, but the biggest frustration is that you spend so much time and energy mocking away Jest’s deficiencies.

Anyways, thanks Copilot for solving the problem my powerless human brain could never answer. In my review of Copilot last year I mentioned using it for writing tests and it’s still proving valuable there. It’s solving the “fear of the blank page” problem. With a little coaxing, I’m able to get 100% coverage on my components for props and conditionals. Copilot seems okay at that. Little less great at mocks, but it can do it. Sometimes the robot is wrong though, so you have pay attention to what the machine is spitting out.

If you’re on the fence about Copilot, I’d recommend it for the sole purpose of having someone else around who will throw spaghetti when you’re tired of throwing spaghetti at the wall. It makes the job a little easier and can unblock you.

After her guide dog runs off after a thief who takes her bag, a girl navigates a world guided by her powerful senses of touch, hearing, and smell. Super charming and inventive. From the YouTube comments:

For those who don’t know, blind people will clap their hands and listen for the echo to get a sense of how big a space they are in, if it’s wide open or a tightly enclosed space.

(via peterme)

Hype warning, but I think HMR in Remix is going to be best implementation I've ever used. We're able to do typical HMR when only rendering code changes, but if server code changes too we revalidate the data before applying HMR, so rendering + server code update the UI together

When using an external API, you may need to keep an access token to send a request as a user. And a refresh token to get a new access token once the access token expires.

In a SPA, you can create a wrapper for your Fetch. Suppose the request is rejected because of an expired access token. In that case, you can refresh it, update your access and refresh token, and try the request again with the new one. From that moment, all future requests will use the new access token.

But what about Remix? What happens if your access token is used inside a loader? You probably stored both tokens in the session, so you need to commit the session to update it, and if more than one loader is running, they may all find the expired token.

To solve this in loaders, we can do a simple trick, refresh the token and redirect to the same URL that will trigger the same loaders. It will update the tokens in the session, so the new request will come with the updated tokens after the redirect.

For actions, it's trickier because you can't redirect and generate a new POST. At the same time, you know that only one action function will be called per request, so you could refresh the token, get the tokens back and set a cookie with the new one.

Let's say how we could create an authenticate function to do that.

// our authenticate function receives the Request, the Session and a Headers
// we make the headers optional so loaders don't need to pass one
async function authenticate(
  request: Request,
  session: Session,
  headers = new Headers()
) {
  try {
    // get the auth data from the session
    let accessToken = session.get("accessToken");

    // if not found, redirect to login, this means the user is not even logged-in
    if (!accessToken) throw redirect("/login");

    // if expired throw an error (we can extends Error to create this)
    if (new Date(session.get("expirationDate")) < new Date()) {
      throw new AuthorizationError("Expired");
    }

    // if not expired, return the access token
    return accessToken;
  } catch (error) {
    // here, check if the error is an AuthorizationError (the one we throw above)
    if (error instanceof AuthorizationError) {
      // refresh the token somehow, this depends on the API you are using
      let { accessToken, refreshToken, expirationDate } = await refreshToken(
        session.get("refreshToken")
      );

      // update the session with the new values
      session.set("accessToken", accessToken);
      session.set("refreshToken", refreshToken);
      session.set("expirationDate", expirationDate);

      // commit the session and append the Set-Cookie header
      headers.append("Set-Cookie", await commitSession(session));

      // redirect to the same URL if the request was a GET (loader)
      if (request.method === "GET") throw redirect(request.url, { headers });

      // return the access token so you can use it in your action
      return accessToken;
    }

    // throw again any unexpected error that could've happened
    throw error;
  }
}

Now, we can define a loader function like this:

export let loader: LoaderFunction = async ({ request }) => {
  // read the session
  let session = await getSession(request);
  // authenticate the request and get the accessToken back
  let accessToken = await authenticate(request, session);
  // do something with the token
  let data = await getSomeData(accessToken);
  // and return the response
  return json(data);
};

And our action functions will be similar:

export let action: ActionFunction = async ({ request }) => {
  // also read the session
  let session = await getSession(request);
  // but create a headers object
  let headers = new Headers();
  // authenticate the request and get the accessToken back, this will be the
  // already saved token or the refreshed one, in that case the headers above
  // will have the Set-Cookie header appended
  let accessToken = await authenticate(request, session, headers);
  // do something with the token
  let data = await getSomeData(accessToken);
  // and return the response passing the headers so we update the cookie
  return json(data, { headers });
};

And that's all. Our loader/action functions will be able to refresh the token and use the new one. In the loader case, a redirect will happen hidden entirely from our code. We don't need to think about it at all.

Note this may change once Remix supports pre/post request hooks, so we could do the auth check in a pre-request hook and do it once.

Another option if you use Express is to move this to the Express request handler in your server code. That will run before Remix, which can happen before all your loaders and actions run in a single request.

The checkmark on a Mastodon account is only as credible as the website it references and the Mastodon server that displays the account.

I think rel=me is such a neat idea. It’s a very “webby” way of doing verification on the internet because it leverages bedrock internet technology (e.g. links) and institutions (e.g. domains and ICANN) to address the problem of identity verification (as opposed to, say, the shifting, fleeting policies of a for-profit corporation).

rel=me powerfully reinforces the importance and value of owning a domain in the digital age.

For example: imagine for a moment the value of google.com. What would that domain cost? People’s entire personal and professional lives — email, photos, calendar, documents, etc. — built up over years and years, solely accessible at that domain.

Now imagine someone who invested years of their life creating value for others and amassing a following on Twitter. They now face a dilemma: all that value lives at a URL they can’t control twitter.com/{username}. Even the word-of-mouth username is something they have zero control over.

• Person 1: “Hey, you should checkout @insightful608 — they’re great!”
• Person 2: “Ah man, didn’t you hear? Twitter is down. Who is @insightful608?”
• Person 3: “Oh, I don’t know. Let me see if I can find them elsewhere on the internet…”

However, if own your domain, create value there, and drive people to it, you’re paying ~$10 a year to build unbounded value over the years — value you control.

That is why owning a domain (and publishing your content there) is like planting a tree: it’s value that starts small and grows. The best time to own a domain and publish your content there was 20 years ago. The second best time is today.

This is the what I love about rel=me: it reinforces the value of owning a domain that people respect and trust because, through the years, it becomes a source of quality information. In an internet connected world, domains are a currency of value. Do you want to own your value, or let someone else own it?

[verification with rel=me] is based on a loose specification created by bloggers back in 2003 called Xhtml Friends Network. Just as with Mastodon, its intention is not to tell us “this account belongs to television host Stephen Fry” but rather “this Stephen Fry account was vouched for by stephenfry.com, the website.”

I love a technology like rel=me which pushes the idea of domain ownership into broader and broader spheres of society — “How do I get that nice little green checkmark on my profile?” It reinforces the value of owning your own domain (which you can verify elsewhere) and encourages citizens of the internet people to build value in their own little corners of the world wide web.

After all, domains are the OG handles of the internet: find me @jim-nielsen.com.

What domain do you want vouching for you?

• Reply via: Email, Twitter, Mastodon

One such bouncing question deals with port numbers. It seems like every time I run npm start on a web project, it’s a roll of the dice as to which port of localhost I’ll get a local dev server on.

I understand perfect uniformity across all projects is unlikely (not everyone will be on port 8000), but it’s also not completely random across the entire spectrum of thousands of ports (I never get a local dev server on 4971 or 9571 or 6373).

Why does the local dev server port always seem to be a random selection between about four to five ports?

I asked on Twitter:

Does somebody have an article like "A short history of port numbers" that describes why I never get a consistent default port experience across tools? Some commons ones I consistently see:

localhost
localhost:3000
localhost:8000
localhost:8080
localhost:8888

And further:

why/where did those numbers pop into our collective culture? why not 2000 or 4000? or why not 6666? or any other random number for that matter?

To be clear, this post is not meant to be the definitive answer to that question. But I read enough random links on the internet to arrive at what feels like a satisfactory answer (though I can’t vouch for the accuracy of it).

So I will try re-stating what I found across various resources on the web and see if I can weave them all into a coherent narrative.

Ports 80**

Ports 0-1023 are considered “system ports” (a.k.a “well-known ports” or “privileged ports”). They are reserved by the system for specific applications.

For example, the following ports are reserved by the system for well-known services:

• 21 FTP
• 25 SMTP
• 80 HTTP
• 443 HTTPS

But why 80 and 443 for HTTP and HTTPS? Why not 51 and 666?

It appears that IANA (a department of ICANN) published RFC1060 in 1990 listing all well-known ports at that point in time and port 80 was unclaimed. When Tim Burners-Lee issued the first version of HTTP in 1991, he used port 80 for HTTP. Later, in 1992, RFC1060 was reissued and port 80 was claimed by HTTP. As for 443, its history is less clear but it officially showed up as claimed by HTTPS in an RFC in 1994.

(Update: turns out, 2784 was the port number for the web before 80 was — thank you Jeremy!)

Ok so, an HTTP server runs on port 80. But what if you’re doing local development? The standard HTTP port 80 is privileged and requires root access (which would be a hassle to provide every time you start the server). Plus, you don’t want your development server interfering with other running processes on your machine. So what you need is an alternative port number for your local dev server that is above 1024.

(Update: turns out macOS no longer enforces privileged ports (Hacker News thread) — thank you Carl Johnson.)

What number do you choose? Well, I’m going to guess that people just wanted a number that was easy to remember so they went with variants of the reserved HTTP port (80) which is how we got conventions for local HTTP servers to run on ports like 8000, 8080, 8888 and 8008^[1].

It appears that lots of services (and malware) were built on top of these well-known HTTP alternative ports. For example:

• Port 8000: was used by VmWare, VMotion, AWS Local DynamoDB, Canon Management Console, Django Dev Server, and Winamp Audio Streaming — but also by malware and spybots.
• Port 8080 was used by Unreal Tournament and Microsoft Lync — but also by trojans and backdoor worm exploits.
• Port 8888 was used by MAMP — but also, you get it, more malware.

Ports 30**

So what about port 3000? That doesn’t even have an eight in it anywhere. Where did that number come from?

I’m personally aware of the prevelance of port 3000 because of its ubiquity in the Node ecosystem. But from what I gather, Ruby (which predates Node) also uses 3000 prevalently (and, as you probably guessed, malware uses it too). Ultimately, I cannot find a story behind that port.^[2]

That said, once a project like Node does something you can imagine how it spreads: for whatever reason, somebody starts using port 3000 in code or docs or examples, and that spreads to become the standard port for starting an HTTP server in Node. From there the number spread like wildfire into the community and tooling (which would explain why the first place I remember seeing port 3000 used in a dev server was when I first used create-react-app).

Conclusion

Phew. I think I have sufficiently answered my own question to a degree of satisfaction where my curiosity will let me rest.

Some additional links from my research:

• “What's the story behind port 8080?” on Quora
• “Why is port 3000 used when running a Node.js application?” on Quora
• “List of TCP and UDP port numbers” on Wikipedia
• “Registered port” on Wikipedia
• “Priviliged ports” on w3.org
• “Service Name and Transport Protocol Port Number Registry” on iana.org
• “Port 8080” in the Port Authority Database (from the Gibson Research Corporation)
• “The History of the URL” on The Cloudflare Blog

1. IANA is responsible for resources related to internet protocols and it appears you can register (i.e. reserve) commonly used port numbers for well-known services. For example, 8008, 8080, and 591 are all considered HTTP alternatives, a.k.a. http-alt. 591 seems like a random outlier, but it appears to be because FileMaker chose to use it as an alternative port (and registered it as one). ↩
2. Port 3000 is registered with IANA for “RemoteWare Client” and “HBCI”. If you Google those names with the people who registered them, the furthest convo back I can find is an obscure mailing list text that sheds no light on the subject. So who knows where 3000 came from. ↩

• Reply via: Email, Twitter, Mastodon

async function showChapters(chapterURLs) {
  for (const url of chapterURLs) {
    const response = await fetch(url);
    const chapterData = await response.json();
    appendChapter(chapterData);
  }
}

This gives the correct result – all the chapters appear in the right order. But, it's kinda slow, because it waits for each chapter to finish fetching before it tries to fetch the next one.

Alternatively, you could do the fetches in parallel:

async function showChapters(chapterURLs) {
  const chapterPromises = chapterURLs.map(async (url) => {
    const response = await fetch(url);
    return response.json();
  });

  const chapters = await Promise.all(chapterPromises);

  for (const chapterData of chapters) appendChapter(chapterData);
}

Great! Except, you're now waiting on the last chapter before showing the first.

For the best performance, do the fetches in parallel, but handle them in sequence:

async function showChapters(chapterURLs) {
  const chapterPromises = chapterURLs.map(async (url) => {
    const response = await fetch(url);
    return response.json();
  });

  for await (const chapterData of chapterPromises) {
    appendChapter(chapterData);
  }
}

However, this has introduced a tricky bug involving unhandled promise rejections.

Unhandled promise rejections

Unhandled promise rejections happen when a promise… is rejected… but isn't handled.

Ok ok, they're like the promise equivalent of an uncaught error. Like this:

const promise = Promise.reject(Error('BAD'));

The rejected state of this promise is 'unhandled' because nothing is dealing with the rejection.

Here are a few ways it could be handled:

// Like this:
try {
  await promise;
} catch (err) {
  // …
}

// Or this:
promise.catch(() => {
  // …
});

// Or even just this:
await promise;
// In this case the promise is handled,
// but a rejection will be turned into a throw.

// Including this:
promise.then(() => {
  // …
});
// …although, since this doesn't handle the rejected case,
// it returns a new promise that's also rejected,
// and that new promise will be unhandled (all new promises are unhandled).

A promise is handled when something is done in reaction to that promise, even if it's creating another rejected promise, or turning a rejected promise into a throw.

Once a promise is rejected, you have until just-after the next processing of microtasks to handle that rejection, else it may count as an unhandled rejection ('may', because there's a little bit of wiggle room with task queuing).

const promise = Promise.reject(Error('BAD'));

// You can handle the promise here
// without it being an 'unhandled rejection'.

queueMicrotask(() => {
  // Or here.
});

setTimeout(() => {
  // But here might be too late.
}, 0);

Unhandled rejections are problematic

Unhandled rejections are a bit like uncaught errors, in that they cause the entire program to exit with an error code in Node and Deno.

In browsers, you get errors appearing in the console, again similar to uncaught errors:

They might also appear in error logging systems, if the system listens for unhandled rejections:

addEventListener('unhandledrejection', (event) => {
  // …Log the error to the server…
});

The point is, you want to avoid unhandled rejections.

But where are the unhandled rejections in the example?

It's not immediately obvious:

async function showChapters(chapterURLs) {
  const chapterPromises = chapterURLs.map(async (url) => {
    const response = await fetch(url);
    return response.json();
  });

  for await (const chapterData of chapterPromises) {
    appendChapter(chapterData);
  }
}

The promises in chapterPromises are handled by the for await in each iteration of the loop. When the loop encounters a rejected promise, it becomes a throw, which abandons the function and rejects the promise showChapters returned.

The bug happens if a promise rejects before the for await handles that promise, or if that promise is never reached.

For example: If chapterPromises[0] takes a long time to resolve, and meanwhile chapterPromises[1] rejects, then chapterPromises[1] is an unhandled rejection, because the loop hasn't reached it yet.

Or: If chapterPromises[0] and chapterPromises[1] reject, then chapterPromises[1] is an unhandled rejection, because the loop is abandoned before it gets to chapterPromises[1].

Ugh. The "unhandled promise rejection" feature is there so you don't 'miss' rejected promises, but in this case it's a false positive, because the promise returned by showChapters already sufficiently captures the success/failure of the operation.

This issue doesn't always involve fetches, it could be any bit of work you start early, then pick up the result later. Like a worker task.

This doesn't always involve for await either. It impacts any situation where you start the work early, then handle the result later, asynchronously.

It wasn't an issue for the Promise.all example:

async function showChapters(chapterURLs) {
  const chapterPromises = chapterURLs.map(async (url) => {
    const response = await fetch(url);
    return response.json();
  });

  const chapters = await Promise.all(chapterPromises);

  for (const chapterData of chapters) appendChapter(chapterData);
}

In this case all the promises in chapterPromises are handled immediately, by Promise.all, which returns a single promise that's immediately handled by the await. But this solution has worse performance than our sequential solution.

What's the real solution?

Unfortunately it's a bit of a hack. The solution is to immediately mark the promises as handled, before they have a chance to become unhandled rejections.

async function showChapters(chapterURLs) {
  const chapterPromises = chapterURLs.map(async (url) => {
    const response = await fetch(url);
    return response.json();
  });

  // TODO: 'handle' every promise in chapterPromises here

  for await (const chapterData of chapterPromises) {
    appendChapter(chapterData);
  }
}

One way to do this is to add a dummy catch handler to each promise:

for (const promise of chapterPromises) promise.catch(() => {});

This doesn't change the promises other than marking them as 'handled'. They're still rejected promises. It doesn't cause errors to be missed/swallowed elsewhere.

A shorter way to achieve the same thing is Promise.allSettled:

Promise.allSettled(chapterPromises);

This works because allSettled handles all the promises you give it, similar to Promise.all, but unlike Promise.all it never returns a rejected promise itself (unless something is fundamentally wrong with the input iterator).

Both of these look pretty hacky, and likely to confuse others that read the code later. Because of this, I'd probably create a helper function like preventUnhandledRejections:

// In promise-utils.js:
export function preventUnhandledRejections(...promises) {
  for (const promise of promises) promise.catch(() => {});
}

And comment its usage:

import { preventUnhandledRejections } from './promise-utils.js';

async function showChapters(chapterURLs) {
  const chapterPromises = chapterURLs.map(async (url) => {
    const response = await fetch(url);
    return response.json();
  });

  // Avoid unhandled rejections leaking out of this function.
  // The subsequent `for await` handles all the relevant promises.
  preventUnhandledRejections(...chapterPromises);

  for await (const chapterData of chapterPromises) {
    appendChapter(chapterData);
  }
}

I wish there was a less 'blunt' way of handling this in JavaScript, but I'm not sure what that would look like. The design of the "unhandled rejections" feature directly clashes with starting work early and handling the result later, or not handling the result if a prerequisite fails.

In the meantime, preventUnhandledRejections does the trick!

For completeness, here's an abortable implementation of showChapters, that also handles bad responses.

Thanks to Surma and Thomas Steiner for proof-reading.

But I found a CSS tricks-y workaround that helps make things a little easier. That’s what I want to show you in this post.

The problem

First we need to understand how layout is handled by the browser. We have the table-layout property in CSS to define how a table should distribute the width for each table column. It takes one of two values:

• auto (default)
• fixed

Let us start with a table without defining any widths on its columns. In other words, we will let the browser decide how much width to give each column by applying table-layout: auto on it in CSS. As you will notice, the browser does its best with the algorithm it has to divide the full available width between each column.

If we swap out an auto table layout with table-layout: fixed, then the browser will merely divide the full available space by the total number of columns, then apply that value as the width for each column:

But what if we want to control the widths of our columns? We have the <colgroup> element to help! It consists of individual <col> elements we can use to specify the exact width we need for each column. Let’s see how that works in with table-layout: auto:

I have inlined the styles for the sake of illustration.

The browser is not respecting the inline widths since they exceed the amount of available table space when added up. As a result, the table steals space from the columns so that all of the columns are visible. This is perfectly fine default behavior.

How does <colgroup> work with table-layout: fixed. Let’s find out:

This doesn’t look good at all. We need the column with a bunch of content in it to flex a little while maintaining a fixed width for the rest of the columns. A fixed table-layout value respects the width — but so much so that it eats up the space of the column that needs the most space… which is a no-go for us.

This could easily be solved if only we could set a min-width on the column instead of a width. That way, the column would say, “I can give all of you some of my width until we reach this minimum value.“ Then the table would simply overflow its container and give the user a horizontal scroll to display the rest of the table. But unfortunately, min-width on table columns are not respected by the <col> element.

The solution

The solution is to fake a min-width and we need to be a bit creative to do it.

We can add an empty <col> as the second column for our <colgroup> in the HTML and apply a colspan attribute on the first column so that the first column takes up the space for both columns:

<table>
  <colgroup>
    <col class="col-200" />
    <col />
    <col class="col-input" />
    <col class="col-date" />
    <col class="col-edit" />
  </colgroup>
  
  <thead>
    <tr>
      <th colspan="2">Project name</th>
      <th>Amount</th>
      <th>Date</th>
      <th>Edit</th>
    </tr>
  </thead>
  
  <!-- etc. -->
</table>

Note that I have added classes in place of the inline styles from the previous example. The same idea still applies: we’re applying widths to each column.

The trick is that relationship between the first <col> and the empty second <col>. If we apply a width to the first <col> (it’s 200px in the snippet above), then the second column will be eaten up when the fixed table layout divides up the available space to distribute to the columns. But the width of the first column (200px) is respected and remains in place.

Voilà! We have a faux min-width set on a table cell. The first cell flexes as the available space changes and the table overflows for horizontal scrolling just as we hoped it would.

(I added a little sticky positioning to the first column there.)

Accessibility

Let’s not totally forget about accessibility here. I ran the table through NVDA on Windows and VoiceOver on macOS and found that all five columns are announced, even if we’re only using four of them. And when the first column is in focus, it announces, “Column one through two”. Not perfectly elegant but also not going to cause someone to get lost. I imagine we could throw an aria-hidden attribute on the unused column, but also know ARIA isn’t a substitute for poor HTML.

I’ll admit, this feels a little, um, hacky. But it does work! Let me know if you have a different approach in the comments… or know of any confusions this “hack” might bring to our users.

Faking Min Width on a Table Column originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Large companies find HTML & CSS frustrating “at scale” because the web is a fundamentally anti-capitalist mashup art experiment, designed to give consumers all the power.

Ooooff. Ponder on that for a while.

I love the web — and what I love about the web, at its core, is something that is individually freeing and runs against the grain of corporate value extraction. How do you make a living ($$$) working on something that you love whose reason for being resists the impulse for capitalization?

The web is full of puzzling but beautiful dualities. It reminds me of Nicholas Carr’s writing where he points out the irony of the web being heralded by early advocates as a tool of liberation but in practice becoming widely (ab)used as an instrument of control.

Could the web, and everything I love about it, even be built as a platform today? Craig Mod wonders this aloud:

I still find it fully miraculous that webpage source code is freely viewable, and browsers allow for trivial editing of the source live and inline

Can just imagine the pushback against if someone tried to launch a platform like this today

It’s quite incredible that the money and power birthed through the advent of the web haven’t yet been able to completely overtake this “mashup art experiment” medium which “gives consumers all the power”.

• Reply via: Email, Twitter, Mastodon

• “New episodes every week. Subscribe wherever you get your podcasts.”
• “Follow us in your podcatcher of choice.”
• “Search for ____ wherever you listen and follow.”

It’s an expression that has entered the larger public consciousness and suggests (albeit an implicit) understanding of an open, distributed web. You don’t go to a singular, centralized, corporate gatekeeper to get your podcasts. Instead, you grab an app — any podcasting app — and all they seem to have access to the same stuff (unless they’re exclusive and you have to pay — cough Spotify cough).

What’s amazing about these phrases — like “Follow us wherever you get your podcasts” — is that they are are paid advertisements that point you to nowhere in particular! It’s not “Stream it now on _Netlix_” or “Follow us on _Facebook_” or even “Visit _ourwebsite.com_”. These are paid advertisements with no “call to action” to any one commercial, corporate platform.

It’s kind of amazing: it’s not just hippie nerds talking about an open, accessible, distributed content model. People and corporations are putting real money into supporting a model that gives users all the power to browse, follow, and access whatever they want, wherever and however they best see fit.

It’s a wonderful phenomenon, articulated well in this Mastodon post from @attacus@aus.social:

“You can find us anywhere you get your podcasts.”

I adore this phrase, because…Podcasts are just out there, like air. You don’t go to one place to get them; you get them from everywhere and anywhere. You can choose how you want to engage with them and manage them

Wouldn’t it be amazing if a similar phrase could enter the larger public consciousness for blogs or even people who you follow online?

Instead of:

• “Follow me on Twitter.”
• “I’m @realChuckieCheese on Instagram.”
• “Subscribe to my videos on YouTube.”

You’d hear some popular influencer saying:

• “Follow me wherever you follow people online.”
• “Find me and subscribe wherever you get your content.”

Imagine a de-centralized model of syndication and supporting third-party apps such that non-techies would know what it means when somebody says, “Follow me online”. It wouldn’t entail being funneled through the digital tools of any one, centralized entity; rather, you’d just grab your favorite app for following people and subscribe!

In a world like this, perhaps apex domains could become the currency of online handles: follow me @jim-nielsen.com. Then, through the magic of auto-discoverable feed URLs, all meta info necessary for any reader to subscribe to any feed of content would become automagically available. Feeds everywhere and feeds can be whatever.

Perhaps, one day, this will be our future.

• Reply via: Email, Twitter, Mastodon
• Related posts linking here: The Best Time to Own a Domain Was 20 Years Ago; The Second Best Time Is Today

LCH isn't linked to a particular color space, and so we don't know where the upper saturation limit is. It's not static: as display technology continues to improve, we can expect monitors to reach wider and wider gamuts. LCH will automatically be able to reference these expanded colors by cranking up the chroma. Talk about future-proofing!

Wait, what?!? LCH syntax has an eye towards future-proofing?? I did not know this!!

I’ve heard LCH proponents talk about why they prefer it — usually it has to do with how it accounts for human perception in color changes. Here’s Lea Verou:

In LCH, the same numerical change in coordinates produces the same perceptual color difference. This property of a color space is called “perceptual uniformity”. RGB or HSL are not perceptually uniform.

That’s neat and solves a real problem I’ve encountered in color transformations.

But this “future-proofing” business? I love that! Granted, technology will always be changing, but a new API that aims for longevity is a hype train I can jump on — and hopefully ride for a very long time. Switching from hex to rgb to hsl to hwb to who knows what next over the years can be a bit exhausting.

Lea explains how LCH is designed to represent the entire spectrum of what humans can see. As such, chroma for example, is theoretically unbounded in the syntax allowing for increased saturation values as hardware improves:

In HSL, saturation is a neat 0-100 percentage, since it’s a simple transformation of RGB into polar coordinates. In LCH however, Chroma is theoretically unbounded. LCH (like Lab) is designed to be able to represent the entire spectrum of human vision, and not all of these colors can be displayed by a screen, even a P3 screen. Not only is the maximum chroma different depending on screen gamut, it’s actually different per color.

Josh illustrates how this concept works in this intriguing code example:

.red-box {
  /* This is a very-red box in sRGB: */
  background: lch(50% 120 20);
  
  /*
    This is an identical color in sRGB, but will appear
    MUCH REDDER in the wider-gamut displays of the future:
  */
  background: lch(50% 500 20);
}

Note how the chroma value is jacked up super high? It’s representing a color visible to the human eye but maybe only visible on certain hardware.

And that’s the beautiful part: this all builds on the idea of progressive enhancement. If a color you specify in LCH is outside the gamut of a given monitor (e.g. you specify a YUGE chroma value) browsers will scale back the value to the closest approximation of that color given the supported hardware. Here’s Lea again:

While the lack of boundaries can be somewhat unsettling (in people and in color spaces), don’t worry: if you specify a color that is not displayable in a given monitor, it will be scaled down so that it becomes visible while preserving its essence. After all, that’s not new: before monitors got gamuts wider than sRGB, this is what was happening with regular CSS colors when they were displayed in monitors with gamuts smaller than sRGB.

Perceptual uniformity? An eye towards longevity? Future-proofing syntax? Graceful fallbacks? Aligned with human anatomy? OK LCH, I’ll jump on your bandwagon.

One color syntax to rule them all!

(BTW: this post on LCH, and color in general on the web, was super helpful for me too!)

Update 2023-01-09

Dan Peterson, who works on 1Password, ping me on Mastodon noting his love for OKLCH after using it on a color token project. He also passed along a bunch of links he found useful during his research. I haven’t gone down the rabbit hole of all these, but they all look super useful so I’m appending them here. Thanks Dan!

• “A perceptual color space for image processing”
• Okhsv and Okhsl
• “It’s time for a more sophisticated color contrast check for data visualizations”
• “An interactive review of Oklab”
• “Designing Color Systems — Transparent vs. Solid Shades”
• “Why APCA as a New Contrast Method?”
• APCA Contrast Calculator
• OKLCH Color Picker & Converter
• Interactive color picker comparison
• Color.js

Update 2021-01-11

In case you’re wondering, the consensus seems to be: you should be using oklch and not lch because oklch fixes a bug in lch (and adds a few new features).

But that ok prefix, where did that come from? I asked on Twitter:

dumb question: is it called "oklch" because it fixes a bug in lch and so it's the "ok" version of lch to use? i can't discern where the "ok" comes from...

And it sounds like that actually is the case, ha! Here’s Björn Ottosson, creator of Oklab:

In many cases simpler models are more practical to use, and should give OK results. Not a lot of effort has gone into finding such simple models though. Oklab/Oklch is my attempt at addressing that, to get OK results without being too complicated.

• Reply via: Email, Twitter, Mastodon

It’s like when you’re learning a new language. At some point your brain goes from translating from your mother tongue into the other language, and instead starts thinking in that other language. Likewise with CSS, at some point you want to stop translating “left” and “right” into “inline-start” and “inline-end” and instead start thinking in terms of inline and block dimensions.

This got me ruminating on design systems work, but also system abstractions in general.

Thinking systematically, you begin to see abstractions in the one-offs which helps you translate the execution of a specific design to traits of a generalized one.

What am I talking about? Take color, for example.

You’re prototyping and you want to use purple, so you reach for a CSS keyword and call it a day with color: purple.

Later you decide there’s a particular hue of “purple” that’s considered “brand purple” so you copy/paste that value and ship it, resulting in CSS like color: #8f00ff.

But, wait: you need that purple in lots of other places, so you name it for reuse and leverage CSS custom properties: var(--color-brand).

But wait again: that tells you what the thing is, not how you should use it. So you devise a purpose for the color within an ordered system by providing it a semantic name which circumscribes its use, role, and function apart from other colors, e.g. var(--color-primary-accent).

You can see how there are different tiers of values, each having its own purpose and trade-offs:

• Approximate value: purple
• Literal value #8f00ff
• Named value --color-brand
• Semantic value --color-primary-accent

The idea of semantic values as vocabulary within a system is useful though not always immediately intuitive. It requires context at a broader level than any single, bespoke design. However, as you work in this model, eventually its language becomes second nature and you stop thinking of color as one-off choices, e.g. #8f00ff, and instead begin thinking of color as relational values disambiguated in purpose by semantic naming, e.g. color-primary-accent.

From this new perspective, there’s no longer “purple” and “green” for use as you see fit, but color-primary-accent and color-secondary-accent for purposeful use within a rationale, ordered system.

• Reply via: Email, Twitter, Mastodon

<h2 id="article1-heading">All About Dragons</h2>  
<p>I like dragons. Blah blah blah blah blah.</p>  
<p>
  <a id="article1-read-more" aria-labelledby="article1-read-more article1-heading">Read more</a>  
</p>  

See that aria-labelledby attribute? It chains two IDs from the markup, one for the heading (#article1-heading) and one for the link (#article1-read-more). What happens there is a screenreader will replace the existing semantic label between the link tags and use the content from both elements and announce them together as a single string of text:

Read more All About Dragons

I’m always sheepish when realizing there’s something I think I should know but don’t. This is definitely one of those cases and I’m thankful as all heck that Suzy shared it.

I was actually in a situation just recently where I could’ve should’ve done this. I always try to avoid a bunch of “Read more” links on the same page but coming up with different flavors of the same thing is tough when you’re working with something like a loop of 15 posts (even though there are resources to help). And if we need to keep labels short for aesthetic reasons — design requirements and whatnot — it’s even more challenging. The aria-labelledby attribute gives me exactly what I want: consistent visual labels and more contextual announcements for assistive tech.

And this is only a thing when the text you want to use for the accessible label already exists on the page. Otherwise, you’d want to go with aria-label and with the caveat that it’s purely for interactive elements that are unable to label things accessibly with semantic HTML.

If you are working in a CMS like WordPress (which I am), you might need to do a little extra work. Like when I drop a Button block on the page, these are the options I have to work with:

Some nice options in there, but nothing to do with accessible labelling. If you’re wondering what’s buried in that Advanced panel:

Instead, you’ll need to edit the button in HTML mode:

But before doing that, you gotta add an ID to the heading you want to use. The Heading block has the same Advanced panel setting for adding an anchor, which’ll inject an ID on the element:

Then you can go edit the Button block in HTML mode and add the accessible-labels ID as well as an ID for the button itself. This is an example of the edited markup:

<div class="wp-block-buttons">
  <!-- wp:button -->
  <div class="wp-block-button">
    <a id="read-more-button" aria-labelledby="read-more-button heading-accessible-labels" class="wp-block-button__link wp-element-button" href="https://webaim.org/projects/million/">
      Read Report
    </a>
  </div>
  <!-- /wp:button -->
</div>

Great! But WordPress just ain’t cool with that:

You can try to resolve the issue:

Le sigh. The Button block has to be converted to a Custom HTML block. Kinda defeats the whole visual editing thing that WordPress is so good at. I did a super quick search for a plugin that might add ARIA labelling options to certain blocks, but came up short. Seems like a ripe opportunity to make one or submit PRs for the blocks that could use those options.

Unchain My Inaccessibly-Labelled Heart originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Tables often rely on having enough screen space to communicate these data relations effectively. This makes designing and developing more complex responsive tables somewhat of a challenge. There is no universal, silver-bullet solution for making the tables responsive as we often see with other elements like accordions, dropdowns, modals, and so on. It all depends on the main purpose of the table and how it’s being used.

If we fail to consider these factors and use the wrong approach, we can potentially make usability worse for some users.

In this article, we’re going to be strictly focused on various ways we can make tables on the web responsive, depending on the data type and table use-case, so we’re not going to cover table search, filtering, and other similar functionalities.

If you are interested in improving user experience (UX) for tables and other UI elements beyond just responsiveness, make sure to check out Smashing Magazine’s incredibly useful Smart Interface Design Patterns workshop, which covers best practices and guidelines for various UI components, tables included.

Before diving into specific responsive table patterns, let’s quickly go over some best practices regarding design and accessibility. We’ll cover some general points in this section and other, more specific ones in later examples.

Design And Visual Features

First, we need to ensure that users can easily scan the table and intuitively match the data to their respective table header elements. From the design perspective, we can ensure the following:

• Use proper vertical and horizontal alignment (“A List Apart” covers this in their article).
• Design a table with clear divisions and optimal spacing between rows and cells.
• Table header elements should stand out and be styled differently from data cells.
• Consider using alternate background color for rows or columns (“zebra stripes”) for easier scanning.

ARIA Roles

We want to include proper ARIA attributes to our table element and its descendants. Applying some CSS styles like display: block or display: flex (to create responsive stacked columns) may cause issues in some browsers. In those cases, screen readers interpret the table element differently, and we lose the useful table semantics. By adding ARIA labels, we can fix the issue and retain the table semantics.

Including these roles in HTML manually could become tedious and prone to error. If you are comfortable about using JavaScript for adding additional markup, and you aren’t using a framework that generates static HTML files, you can use this handy little JavaScript function made by Adrian Roselli to automatically add ARIA roles to table elements:

function AddTableARIA() {
  try {
    var allTables = document.querySelectorAll("table");
    for (var i = 0; i < allTables.length; i++) {
      allTables[i].setAttribute("role", "table");
    }
    var allRowGroups = document.querySelectorAll("thead, tbody, tfoot");
    for (var i = 0; i < allRowGroups.length; i++) {
      allRowGroups[i].setAttribute("role", "rowgroup");
    }
    var allRows = document.querySelectorAll("tr");
    for (var i = 0; i < allRows.length; i++) {
      allRows[i].setAttribute("role", "row");
    }
    var allCells = document.querySelectorAll("td");
    for (var i = 0; i < allCells.length; i++) {
      allCells[i].setAttribute("role", "cell");
    }
    var allHeaders = document.querySelectorAll("th");
    for (var i = 0; i < allHeaders.length; i++) {
      allHeaders[i].setAttribute("role", "columnheader");
    }
    // This accounts for scoped row headers
    var allRowHeaders = document.querySelectorAll("th[scope=row]");
    for (var i = 0; i < allRowHeaders.length; i++) {
      allRowHeaders[i].setAttribute("role", "rowheader");
    }
    // Caption role not needed as it is not a real role, and
    // browsers do not dump their own role with the display block.
  } catch (e) {
    console.log("AddTableARIA(): " + e);
  }
}

However, keep in mind the following potential drawbacks of using JavaScript here:

• Users might choose to browse the website with JavaScript turned off.
• The JavaScript file may not be downloaded or may be downloaded much later if the user is browsing the website on an unreliable or slow network.
• If this is bundled alongside other JavaScript code in the same file, an error in other parts of the file might prevent this function from running in some cases.

Adding An a11y-Friendy Title

Adding a title next to the table helps both sighted users and users with assistive devices get a complete understanding of the content.

Ideally, we would include a caption element inside the table element as a first child. Notice how we can nest any HTML heading element as a child to maintain the title hierarchy.

<table>
  <caption>
    <h2>Top 10 best-selling albums of all time</h2>
  </caption>

   <!-- Table markup -->
</table>

If we are using a wrapper element to make the table scrollable or adding some other functionality that makes the caption element not ideal, we can include the table inside a figure element and use a figcaption to add a title. Make sure to include a proper ARIA label on either the table element or a wrapper element and link it to a figcaption element:

<figure>
  <figcaption id="caption">Top 10 best-selling albums of all time</figcaption>
  <table aria-labelledby="caption"><!-- Table markup --></table>
</figure>

<figure>
  <figcaption id="caption">
    <h2>Top 10 best-selling albums of all time</h2>
  </figcaption>
  <div class="table-wrapper" role="group" aria-labelledby="caption" tabindex="0">
    <table><!-- Table markup --></table>
  </div>
</figure>

There are other accessibility aspects to consider when designing and developing tables, like keyboard navigation, print styles, high contrast mode, and others. We’ll cover some of those in the following sections. For a more comprehensive guide on creating accessible table elements, make sure to check out Heydon Pickering’s guide and Adrian Roselli’s article which is being kept up to date with the latest features and best practices.

Sometimes we don’t have to make any major changes to our table to make it responsive. We just need to ensure the table width responds to the viewport width. That can be easily achieved with width: 100%, but we should also consider setting a dynamic max-width value, so our table doesn’t grow too wide on larger containers and becomes difficult to scan, like in the following example:

table {
  width: fit-content;
}

With the fit-content value, we ensure that the table doesn’t grow beyond the minimum width required to optimally display the table contents and that it remains responsive.

The table responds to viewport size, and it looks good on small screens, but on wider screens, it becomes difficult to scan due to the unnecessary space between the columns.

We can also ensure that the table max-width value always adapts to its content. We don’t have to rely on assigning a magic number for each table or wrap the table in a container that constrains the width to a fixed value.

This works well for simple tables that don’t require too much screen space to be effectively parsed and aren’t affected by word-break. We can even use fluid typography and fluid spacing to make sure these simple tables remain readable on smaller screens.

/* Values generated with Utopia https://utopia.fyi/type/calculator/ */

tbody {
  font-size: clamp(1.13rem, calc(0.35rem + 2.19vw), 1.75rem);
}

tbody td {
  padding-top: clamp(1.13rem, calc(0.35rem + 2.19vw), 1.75rem);
  padding-bottom:  clamp(2rem, calc(0.62rem + 3.9vw), 3.11rem);
}

This is important to know because on some devices, like smartphones and tablets, scrollbars aren’t visible right away, and users might get the impression that the table is not scrollable.

Lea Verou and Roman Komarov have suggested using “scrolling shadows” to subtly indicate the scrolling direction using gradient background and background-attachment property. Using this property, we can set background gradient behavior when scrolling. We also use linear gradients as edge covers for shadows, so we gradually hide the shadow when the user has reached an edge and cannot scroll in that direction anymore.

.table-wrapper {
  overflow: auto;
  background: 
    linear-gradient(90deg, var(--color-background) 20%, rgba(255, 255, 255, 0)),
    linear-gradient(90deg, rgba(255, 255, 255, 0), var(--color-background) 80%) 
                    100% 0,
    radial-gradient(farthest-side at 0 0%, var(--color-shadow), rgba(0, 0, 0, 0)),
    radial-gradient(farthest-side at 100% 0%, var(--color-shadow), rgba(0, 0, 0, 0))
                    100% 0;
  background-repeat: no-repeat;
  background-size: 20% 200%, 20% 200%, 8% 400%, 8% 400%;
  background-attachment: local, local, scroll, scroll;
}

Keep in mind that background-attachment property is not supported on iOS Safari and a few other browsers, so make sure to either provide a fallback or remove the background on unsupported browsers. We can also provide helpful text next to the table to make sure users understand that the table can be scrolled.

Forcing Table Cropping

We can also dynamically set the table column width to enforce table cropping mid-content, so the user gets a clear hint that the table is scrollable. I’ve created a simple function for this example. The last column will always get cropped to 85% of its size, and we’ll reduce the number of visible columns by one if we cannot show at least 5% of the column’s width.

function cropTable(visibleCols) {
  const table = document.querySelector("figure");
  const { width: tableWidth } = table.getBoundingClientRect();
  const cols = table.querySelectorAll("th, td");
  const newWidth = tableWidth / visibleCols;

  // Resize columns to fit a table.
  cols.forEach(function(col) {
    // Always make sure that col is cropped by at least 15%.
    col.style.minWidth = newWidth + (newWidth * 0.15) + "px";
  });

  // Return if we are about to fall below min column count.
  if (visibleCols <= MIN_COLS) {
    return;
  }

  // Measure a sample table column to check if resizing was successful.
  const { width: colWidth } = cols[0].getBoundingClientRect();

  // Check if we should crop to 1 column less (calculate new column width).
  if (colWidth * visibleCols > tableWidth + newWidth * 0.95) {
    cropTable(visibleCols - 1);
  }
}

This function might need to be adjusted to a more complex use case. Check the example below and see how the table column width responds to window resizing:

The stacking approach has been a very popular pattern for years. It involves converting each table row into a block of vertically stacked columns. This is a very useful approach for tables where data is not comparable or when we don’t need to highlight the hierarchy and order between items.

For example, cart items in a webshop or a simple contacts table with details — these items are independent, and users primarily scan them individually and search for a specific item.

As mentioned before, converting the table rows to blocks usually involves applying display: block on small screens. However, as Adrian Roselli has noted, applying a display property overrides native table semantics and makes the element less accessible on screen readers. This discovery was jarring to me, as I’ve spent years crafting responsive tables using this pattern without realizing I was making them less accessible in the process.

It’s not all bad news, as Adrian Roselli notes the following change for Chrome version 80:

Big progress. Chrome 80 no longer drops semantics for HTML tables when the display properties flex, grid, inline-block, or contents are used. The new Edge (ChromiEdge) follows suit. Firefox still dumps table semantics for only display: contents. Safari dumps table semantics for everything.

— Adrian Roselli

For this example, we’ll use display: flex instead of using display: block for our stacking pattern. This is not an ideal solution as other browsers might still drop table semantics, so make sure to test the accessibility on various browsers and devices.

/* Small screen width styles */
table, tbody, tbody tr, tbody td, caption {
  display: flex;
  flex-direction: column;
  width: 100%;
  word-break: break-all;
}

See the Pen Table - stacked [forked] by Adrian Bece.

Accordion

The stacking pattern might look nice initially and seems to be an elegant solution from a design perspective. However, depending on the table and data complexity, this pattern might significantly increase page height, and the user might have to scroll longer to reach the content below the table.

One improvement I found interesting was to show the primary data column (usually the first column) and hide the less important data (other columns) under an accordion. This makes sense for our example, as users would first look for a name by contact and then scan for their details in the row.

<tr>
  <td onclick="toggle()">
    <button aria-label="Expand contact details">
      <!-- Icon -->
    </button>
    <!-- Main content-->
  </td>
  <td><!-- Secondary content--></td>
  <td><!-- Secondary content--></td>
  <td><!-- Secondary content--></td>
</tr>

We’ll assume that the first table column contains primary data, and we’ll hide other columns unless a row-active class is applied:

/* Small screen width styles */

thead tr > *:not(:first-child) {
  display: none;
}

tbody,
tbody tr,
tbody td {
  display: flex;
  flex-direction: column;
  word-break: break-all;
}

tbody td:first-child {
  flex-direction: row;
  align-items: center;
}

tbody tr:not(.row-active) > *:not(:first-child) {
  max-width: 0;
  max-height: 0;
  overflow: hidden;
  padding: 0;
}

Now we have everything in place for showing and hiding table row details. We also need to keep in mind the screen reader support and toggle the aria-hidden property to hide secondary info from screen readers. We don’t need to toggle the ARIA property if we’re toggling the element visibility with the display property:

function toggle() {
  const row = this.window.event.target.closest("tr");
  row.classList.toggle("row-active");

  const isActive = row.classList.contains("row-active");

  if (isActive) {
    const activeColumns = row.querySelectorAll("td:not(:first-child)");
    activeColumns.forEach(function (col) {
      col.setAttribute("aria-hidden", "false");
    });
  } else {
    const activeColumns = row.querySelectorAll(`td[aria-hidden="false"]`);
    activeColumns.forEach(function (col) {
      col.setAttribute("aria-hidden", "true");
    });
}

We’ll assign this function to the onclick attribute on our main table column elements to make the whole column clickable. We also need to assign proper ARIA labels when initializing and resizing the window. We don’t want incorrect ARIA labels applied when we resize the screen between two modes.

function handleResize() {
  const isMobileMode = window.matchMedia("screen and (max-width: 880px)");
  const inactiveColumns = document.querySelectorAll(
    "tbody > tr > td:not(:first-child)"
  );

  inactiveColumns.forEach(function (col) {
    col.setAttribute("aria-hidden", isMobileMode.matches.toString());
  });
}

//On window resize
window.addEventListener("resize", handleResize);

// On document load
handleResize();

See the Pen Table - accordion [forked] by Adrian Bece.

This approach significantly reduces table height on smaller screens compared to the previous example. The content below the table would now easily be reachable by quickly scrolling past the table.

Going back to our scrollable table example, in some cases, we can give users an option to customize the table view by allowing them to show and hide individual columns, temporarily reducing table complexity in the process. This is useful for users that want to scan or compare data only by specific columns.

We’ll use a checkbox form and have them run a JavaScript function. We’ll only have to pass an index of the column that we want to toggle. We’ll have to hide both the columns in data rows in a table body and a table header element:

function toggleRow(index) {
  // Hide a data column for all rows in the table body.
  allBodyRows.forEach(function (row) {
    const cell = row.querySelector(`td:nth-child(${index + 1})`);
    cell.classList.toggle("hidden");
  });

  // Hide a table header element.
  allHeadCols[index].classList.toggle("hidden");
}

This is a neat solution if you want to avoid the stacking pattern and allow users to easily compare the data but give them options to reduce the table complexity by toggling individual columns. In this case, we’re using a display property to toggle the visibility, so we don’t have to handle toggling ARIA labels.

See the Pen Responsive table - column toggle [forked] by Adrian Bece.

Table complexity and design depend on the use case and the data they display. They generally rely on having enough screen space to display columns in a way user can easily scan them. There is no universal solution for making tables responsive and usable on smaller screens for all these possible use cases, so we have to rely on various patterns.

In this article, we’ve covered a handful of these patterns. We’ve focused primarily on simple design changes with a scrolling table pattern and a stacking pattern and began checking out more complex patterns that involve adding some JavaScript functionality.

In the next article, we’ll explore more specific and complex responsive table patterns and check out some responsive table libraries that add even more useful features (like filtering and pagination) to tables out of the box.

References

• “Tables, CSS Display Properties, And ARIA”, Adrian Roselli
• “A Responsive Accessible Table”, Adrian Roselli
• “Functions To Add ARIA To Tables And Lists”, Adrian Roselli
• Data Tables, Heydon Pickering
• “Table Design Patterns On The Web”, Chen Hui Jing
• “Pure CSS Scrolling Shadows With background-attachment: local”, Lea Verou
• Tables Caption & Summary, Web Accessibility Initiative
• Tables Tips And Tricks, Web Accessibility Initiative

If we get a View Transitions API that works across page navigations, it could potentially turbo-charge the web. It will act as a disincentive to building single page apps—you’d be able to provide swish transitions without sacrificing performance or resilience at the alter of a heavy-handed JavaScript-only architecture.

While getting browser-native support for transitions could act as an antidote to the JavaScript-heavy SPA experiences common today, I think there’s another equally significant change that could decrease the amount of JavaScript shipped to modern websites: we need either 1) more APIs that speak FormData, or 2) browsers that speak JSON.

Allow me to try and explain.

JSON Requires JavaScript

A big impediment to moving away from SPAs is that we’ve collectively spent years building up an entire infrastructure of backend services which power the internet by communicating with browsers in JSON — a format that is not the default method of communication for web browsers. Browsers cannot communicate user actions over the network as JSON without the use of JavaScript. It’s impossible.

What do I mean by this?

By default, browsers make requests via HTTP methods (GET, POST). If a server responds with HTML, the browser knows how to render a UI from that response. If a server responds with JSON, the browser can’t render any UI unless it has some corresponding JavaScript instructions telling it how. JSON requires JavaScript to render any kind of user interface. HTML does not. Browsers know how to turn HTML into human-readable, user-actionable interfaces with or without JavaScript.

In this way, browsers communicate and render GUIs at their most basic level in HTML via HTTP.

• <a> element clicked? That’s an HTTP GET for another resource whose response, if HTML, will render something new in the browser.
• <form> element submitted? That’s an HTTP GET or POST with user-supplied data for another resource whose response, if HTML, will render something new in the browser.

The <form> element in HTML allows users to supply data to the browser and send it to a server without the use of JavaScript. Browsers do this on their own by sending a request, not as application/json, but as application/x-www-form-urlencoded (the default MIME type of a form submission). To send an HTTP request as JSON requires that the client have JavaScript enabled and working (bug free).

To reiterate: every request a browser makes with a JSON payload requires functioning JavaScript — every newsletter signup, every contact inquiry, every account creation request, every e-commerce purchase, every you name it. No exceptions.

That’s pretty wild when you think about it. Why are there so many APIs that communicate solely in JSON on the web when browsers can’t even POST in JSON without JavaScript? Granted, many APIs probably aren’t designed to communicate directly with browsers — but many are and yet they only speak JSON! In those cases, that is assuming a lot by not even communicating in the lingua franca of the browser.

I can’t help but think: only once we start building web APIs that speak in the default communication idiom of browsers will be able to break out of a complete reliance on JavaScript.

To put it bluntly: there’s no progressive enhancement if all your APIs only accept JSON payloads directly from the browser.

If you stopped shipping all JavaScript to the client tomorrow, would the backend services you depend on support receiving information via the browser’s default mechanism for sending user data?

A Simple Example

Imagine I have a simple static site with a call to action to sign up for my newsletter. I drop a static HTML file on a web server with some <form> markup which the browser will use to render a GUI where the user can enter their information.

<form>
  <label for="email">
    Sign Up For My Newsletter
  </label>
  <input type="email" id="email" />
  <button type="submit">
    Sign Up
  </button>
</form>

Now I need a server somewhere to collect this information and store it.

So many third-party services have APIs you can integrate with and guess what? They probably speak JSON exclusively. But browsers don’t send user-entered data as JSON by default, so what’s one to do? You can:

1. Create a URL that accepts the structure of a default browser POST request (<form method="post" action="/my-url">).
2. Throw progressive enhancement out the door, expect JavaScript to work for all your users, and drop a <script> tag on the page somewhere that handles the logic to submit a JSON payload to whatever service will store this information for you.

While I love JAMStack and everything it has done to simplify and make more accessible many aspects of web development, this is a trade-off that cuts deep. Funnily enough, the trade-off is in the very name: JAM standing for JavaScript, APIs, and Markup. In other words, it assumes — even implicitly requires — JavaScript as a functioning dependency in the browser^[1].

Once you need to collect one simple piece of data from a user on a “static” web page — like <input type="email" /> — you either 1) now need to control a server that accepts application/x-www-form-urlencoded payloads, or 2) need to require JavaScript for your page to work.

Quick plug: this is where a framework like Remix which supports progressive enhancement really shines. Remix makes it incredibly easy to support <form> submissions as the browser default application/x-www-form-urlencoded type or as a JavaScript-enhanced application/json type. Read the docs for more info.

Conclusion

In a recent article, Remy Sharp comments that a form should be postable without JavaScript which, as noted above, means that an associated endpoint that speaks more than just JSON is required.

A form should be postable without JavaScript. For instance, I'm sending you my contact details - if JavaScript broke (bad connection) or is disabled (you're spamming my face with subscribe notices), then a form should post details to the server and then reload with page like "thanks for you deets". Not rocket science.

Try to implement that using Next.js…and I can't think…how. You can post to "api endpoint", but that'll return JSON…I'm sure there's a work around, but the point is that it has to be worked around, intentionally.

I think until we start building our APIs to speak in more than just JSON — or we get browsers to speak JSON without requiring JavaScript^[2] — it’s going to be difficult for progressively-enhanced web pages to gain traction over JavaScript rendered apps.

1. To their credit, the folks at Netlify support <form> submissions without JavaScript though I would hazard a guess that feature isn’t used nearly as often as a JavaScript e.preventDefault() on the form submission and the sending of a JSON payload instead. Third-party JSON APIs are so often the recipients of user data entered directly in the browser. If anybody out there is using Netlify’s <form netlify> feature to support progressive enhancement, hit me up with the details on how you’re doing it! ↩
2. AFAIK, there’s no way (currently) to declaratively describe a form in HTML that makes a request with JSON (though there appears to have been an effort to do so at one point). ↩

• Reply via: Email, Twitter
• Related posts linking here: Remix and the Alternate Timeline of Web Development

He argues that building websites is not about clinging to an ideal like the separation of concerns: markup separate from styles separate from scripts. Instead, it’s about the humans — about building technology solutions that can defer to user preferences. What we humans want and need varies from one moment to the next, from one human to the next, and we need technology that accommodates that.

As a simple example, many news sites offer separate, trimmed-down versions of their sites:

• text.npr.org
• lite.cnn.com
• lite.pbs.org

These are great because they recognize the one-size-fits-all approach to providing a website doesn’t cater to the vast needs and preferences of users.

Not only do demographics vary wildly, but within and across demographics needs are always changing and contextual to attributes of a user’s current state like environment, device, or capability. For example, NPR notes the purpose (one of many, I’m sure) of their text-only website:

We have a text-only version of our website for anyone who needs to stay up-to-date on Hurricane Florence news and keep their battery and data usage to a minimum

Somebody visiting text.npr.org to preserve battery and decrease bandwidth because they’re in a Hurricane disaster zone probably needs a lite version for every website they visit, not just NPR.

What Kyle suggests is a world where you don’t need remember separate domains based on the experience you want. Rather, you visit the same domains you always visit, but with the ability to express a preference for the fidelity of experience you want/need in any given moment.

Kyle gives an example of how this could work: a browser-level control to indicate the “fidelity” of the experience you want, e.g. how much bandwidth, CPU, and battery are required to load and interact with the page (note the slider at the top where the URL bar is).

In other words, rather than going to text.npr.org when you want a lean experience, you always go to npr.org but you set your “fidelity preference” to “low”. In theory, this sends a header to NPR indicating you want a “low fidelity” version of the website, e.g. text-only.

From there, it’s up to the site owners to figure out how that user preference maps to an available version of the site. Kyle illustrates this with an example routing configuration.

Granted, there would have to be some kind of rough consensus about what this spectrum of fidelity means. For example, “0” means HTML only: no styles or scripts (inline or external) or even inline images. From there, you build up.

A site may intentionally provide a fidelity that, on the generalized scale may only be a “0.4” but is the highest fidelity offered. That’s a good thing, it means their site will be fast by default, even if the user’s preferred setting across sites is “0.8”.

The thing is, we don’t have to wait for browsers to adopt this. As Kyle suggests, we can start now.

Granted, a browser-level feature would be the ideal here, as it would allow a persistent experience of fidelity across sites. Imagine going from CNN to NPR to PBS and maintaining a (roughly) similar experience of fidelity across websites!

A Quick Aside on CSS

Experiencing various appearances of a website — i.e. keep the same markup but only change the stylesheet — is cool, like CSS Zen Garden.

But that’s not what I’m trying to get at here. I’m not talking about varying styles based on user preference. I’m talking about varying experiences based on user preference. The styles change, but so too does the HTML and the JavaScript.

While I love the idea of a media feature like @prefers-reduced-data, the fact is: if someone really wants a leaner experience of your website, you need to know that at request time. That’s a preference that, in my opinion, transcends CSS. A preference for reduced data means less resources, including HTML, CSS, and JavaScript. How do you control a preference for reduced data in CSS alone?

For example, one end of fidelity is 0. To me, this is pure HTML with no embedded or inlined resource dependencies. No styles. No JavaScript. Not even an <img> tag. We’re talking the most lean experience you can provide. If you opened the console, you’d only see one request: the .html file.

How would you handle <img> then? Hyperlink it! Instead of:

<img src="elephant.jpg" alt="An image of an elephant." />

You do:

<a href="elephant.jpg">[An image of an elephant.]</a>

You can’t do that with @prefers-reduced-data. That’s why the idea of fidelity as a preference in a request header seems crucial. Not just customizeable themes, but customizeable experiences.

My Implementation

Given all the above, I wanted to try this out as a site-level preference on my blog. I implemented it as three separate preferences: Default, Minimal, and Text-Only.

The controls for this fidelity preference vary, based on which version of the site you’re looking at.

“Default” is the experience you get if you have no preference set (how the web works today). “Minimal” is set around the core experience of reading the site: no JavaScript and just a few basic styles. Text-only is my theoretical “fidelity 0”: no styles, no JavaScript, no inline images, as small a site as can be.

Because I wanted this feature to work without JavaScript — that is, after all, part of the essence of the feature — it works by setting a cookie which persists across requests. Choosing a preference sets a cookie and the server knows which version of the site to serve based on the presence of a given cookie (a browser-level request header in the future would be nice, something that’s present upon every client request).

Technical Details

In my case, I am using Netlify and a static site generator to serve my blog, so I wanted to try accomplishing this feature with those constraints.

In essence, it works by having three versions of my site. The first version (the “Default” version) is in the root folder while the other two versions are nested in named folders. Example:

.
├── index.html
├── _fidelity/
     ├── low/
     │    └── index.html
     └── med/
          └── index.html

Using Netlify’s redirects, I route requests to the appropriate version of the site based on the presence of a cookie.

[[redirects]]
  from = "/*"
  to = "/_fidelity/low/:splat"
  status = 200
  force = true
  conditions = { Cookie = ["fidelity-low"] }

[[redirects]]
  from = "/*"
  to = "/_fidelity/med/:splat"
  status = 200
  force = true
  conditions = { Cookie = ["fidelity-med"] }

This is a little convoluted, but again, working within the constraints I have I think it works. (Fortunately, my site is pretty basic.)

As for the different “fidelities” of the site, I accomplished this using a form of backwards progressive enhancement: I generate the “Default” version of my site and then strip features out in stages to lower the fidelity. (Thank goodness I built my blog in a progressively-enhanced way, or I could not have done this without breaking the site!)

For example, to generate the “Minimal” version of the site, I take the “Default” version, strip out tags like <script>, <style>, <link rel=stylesheet>, etc., and inject a separate “basic” stylesheet (~25 lines of CSS, inspired by Robin Rendle and Frank Chimero).

To generate the “Text-Only” version, I take the “Minimal” version, strip out the remaining styles, and swap out inline images for inline links.

This leaves me with three experiences of my site, which I would summarize as:

• Default: All the bells and whistles (yet still lean and mean). Custom theme selection, styled motifs, and any extras — including JavaScript.
• Minimal: Basic enhancements to the core reading experience, including inline images and a base stylesheet for improved layout, but otherwise nothing else (no JavaScript).
• Text-Only: Leanest experience possible. No styles, interactivity, or inline images. Saves bandwidth, CPU, and battery.

I’m using Metalsmith as my static site generator, so you can peak at the code if you want. The above approach results in a slower build that I would prefer as I accomplish generating each version of the site by creating each page as a JSDOM document and using .querySelector to strip stuff out.

In the future, I’ll probably generate the site by running my templating pass three distinct times with a configuration value like fidelity=(low|med|default) and, based on the presence of that value, render things appropriately. Example:

<head>
  ${fidelity === 'default' &&
    `<link
      rel=stylesheet
      href=/styles/default.css
    />`
  }
  ${fidelity === 'med' &&
    `<link
      rel=stylesheet
      href=/styles/basic.css
    />`
  }
  <!-- No styles if fidelity === 'low' -->
</head>

Admittedly, this would be simpler if I was using a server to generate pages at request time. Perhaps I’ll go that direction someday – in the meantime, I’m working with what I’ve got in static file hosting.

There’s a lot more I could write about this, but maybe I’ll split those out into different posts. If you decide to try this out on your site, hit me up with a link!

Y’know that situation where you tell the client, “Here’s your website and you can edit those four (4) little homepage features in the CMS” and the client says “Okay okay okay” and you check the site a week later and it looks bad because the client —despite your incredible documentation— put an odd number of items in the feature grid. It’s a major minor problem that’s tough to explain to the client, but it all comes down to…

The dangler.

Odd number grids are a sore point in Responsive Design. Even numbered grids collapse easily from 4 columns → 2 columns → 1 column, but odd numbered grids leave you with one extra column to figure out. You have two choices: drop the odd column to its own row or take the coward’s route and convert 3 columns → 1 column prematurely at ~800px. If you take that route, two more choices appear: awkwardly center the content or awkwardly stretch all the items out. This is how painful-looking tablet views are born.

You can design your way out of the dangler conundrum. What if we could detect odd numbered columns and make the first item full-width? And then, what if we could give it a horizontal treatment when there’s extra space?

Using :has() to find odd-numbered grids 🪄

Jeffrey Zeldman, Eric Meyer, Chris Coyier, and I were talking on Shoptalk about how the new CSS feature :has() potentially changes how we do CSS. “Contextual Web Design”, I called it. We drummed up some examples but I’ll confess I’m still wrapping my head around what :has() can do. Jim Nielsen came up with some ideas for :has() and that got the gears turning in my brain.

The algorithm I’m going after is pretty simple: If the grid of items has an odd number of items, then make the first item full-width. But CSS can’t do logic… right? Well… hold my proverbial beer.

.items {
	display: grid;
	grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
	gap: 5vw;
}

@media (max-width: 800px) {
	.items {
    grid-template-columns: 1fr 1fr;
  }
	
	.items:has(.item:last-of-type:nth-of-type(odd)) .item:first-of-type {
		grid-column: 1 / -1;
	}
}

There’s two bits of magic going on. I’m using auto-fit instead of auto-fill on the grid to make sure our grid doesn’t create any ghost columns 👻. And then the most essential bit of code is the :has() selector statement.

.items:has(.item:last-of-type:nth-of-type(odd)) .item:first-of-type {
	grid-column: 1 / -1;
}

The result almost reads as plain English. This will select item grids where the last item is odd (read: it’s an odd-numbered grid) and then set the first item to span the full-width from column 1 (the start) to column -1 (the end). 🎉 Tada! Magic.

Using Container Queries to flex differently

Now that we can make an item go full-width, we don’t want to create a “top dangler” problem, that would be even worse than a “bottom dangler”. Ideally, we can apply a different treatment to give this element a horizontal treatment when its container is wide.

This sounds like a job for Container Queries! If the item container is >400px (the image size), then make the item’s inner contents display as a horizontal row.

.item {
  container-name: item;
  container-type: inline-size;
}

@container item (min-width: 400px) {
  .item_inner {
    display: flex;
    flex-direction: row;
    align-items: center;
  }
}

And there you go! A card-like item that changes its presentation based on its width, independent of the viewport and contextual to its parent container¹.

Putting it all together

On their own each of these tricks is great. But together, they create something special: a content machine that applies styles conditionally based on quantity and size of the content inside. I made a demo of this in CodePen so you can give it a squeeze.

⚠️ As of July 2022, this only works in Safari Technical Preview and Edge/Chrome Canary.

Container Queries are a real gift here. In fact, Container Queries solved a problem I hadn’t even considered… what if the client entered two (2) items in the CMS and then someone visits on desktop. Thankfully our auto-fit grid + Container Queries handle that edge case without breaking a sweat, filling the space in the least awkward manner possible. Best of all, this technique progressively enhances, so older browsers get the old dangler experience.

Making the first item full-width is an old RWD trick; it’s worth noting you can do this with some JavaScript, or some class soup, or something like <div class="items" data-count="3"> on your item grid. That’s fine, but I think you’ll feel the pain of coupling and cramming a lot of logic in your item grid component. Even though I’m good at CSS, I tend to avoid styling the first child like this because of the layout complexity it introduces…

But now… now the complexity is almost gone thanks to :has() and Container Queries. What a gift. We truly are entering a new era for CSS, an era where your content informs your layout, not the other way around.

(Before we continue, I’m going to assume you’re already sold on the value of using web components and shadow DOM encapsulation, and have a working knowledge of web component standards/APIs and how to construct a basic custom element.)

The state of custom form elements in 2022 #

Web component standards came on the scene about 11 years ago and introduced the concept of custom elements: blank canvases that we can define, encapsulate, and reuse in ways that we can’t with plain HTML. They changed how we think about extensibility in complex, large scale sites and applications.

When it comes to form composition, though, they require that we reinvent the wheel to some extent. We need custom elements to function exactly like their HTML counterparts — with a focus state, keyboard events, and when set up with a proper <form> and submit button, data validation and serialization — and in ways that leverage HTML itself. That would be my ideal scenario: to seamlessly use HTML form controls in the context of web components.

Web standards and browser vendors are getting there #

The ElementInternals API is meant to, essentially, apply HTML’s form capabilities to custom elements. Think: automatic form data serialization like the good old days, just drop in your form elements, specify how and where to submit, and the browser does the rest. Browser support remains incomplete (no Safari); in the meantime there’s a polyfill.

We also have the global is attribute for extending built-in HTML form elements, but are still waiting on full support in Safari (Mac or iOS).

Until these features are fully implemented in all major browsers (ahem, Safari), it’s up to front-end developers to ensure that custom form elements work.

A checklist for building forms with custom elements #

Whether you use a web component framework or library, or build your own from scratch, when using custom elements to compose forms we have to make sure they meet the standards set by HTML:

1. Does the custom element sufficiently recreate HTML functionality?
2. Do elements maintain id and name associations?
3. Can you programmatically assign focus to each element?
4. Do the events you care about bubble from the shadow DOM?
5. Does your form submit with data?

Let’s get into it!

(Examples below can be found at this CodePen.)

1. Does the custom element sufficiently recreate HTML functionality? #

When users encounter a custom form element, they expect it to act like an HTML form element, which means it should:

• gain focus via user interaction
• support mouse and key events
• maintain states, like disabled or invalid
• capture one or more values
• validate the data (when enabled), and
• submit data with the form.

One of the simplest ways to to accomplish most of the above is use an HTML element at the core of your custom element (or use a library that does, like Ing’s Lion or Shoelace).

A simple example:

class SimpleInput extends HTMLElement {
  constructor() {
    super();
    const shadow = this.attachShadow({
      mode: 'open'
    });
    const input = document.createElement('input');
    // ...add some features here...  
    shadow.appendChild(input);
  }
}

That’s referenced in markup as:

<simple-input></simple-input>

To a user, the HTML input rendered inside <simple-input> behaves as expected, with a default focus state and built-in keyboard interactions. Some edits are still needed, but this method means you don’t have to start at zero, and it lowers the risk of omitting accessibility and other expected features.

To round out the functionality, I defined a couple of attributes (de facto properties) on the custom element that let us pass global and element-specific attribute values to the HTML input:

class SimpleInput extends HTMLElement {
  constructor() {
    super();
    const shadow = this.attachShadow({
      mode: 'open'
    });
    const input = document.createElement('input');

    // set default value, if any
    if (this.hasAttribute('value')) {
      let val = this.getAttribute('value');
      if (val) input.value = val;
    }

    // check for required attr
    if (this.hasAttribute('required')) {
      // set corresponding input property
      input.required = true;
      // by default, the field is invalid until filled in
      this.setAttribute('invalid', true);
    }
 
    shadow.appendChild(input);
  }
}

<simple-input
  value="123 Main Street"
></simple-input>

<simple-input
  required
></simple-input>

2. Do elements maintain id and name associations? #

When the shadow DOM is enabled, no. Elements within don’t communicate with elements outside that shadow DOM, including the enclosing form, label or fieldset, or other sibling form elements (like radio buttons).

A fix for this is on the horizon. The Accessibility Object Model has proposed that idrefs cross shadow root boundaries (see Phase 2). It’ll be fantastic when browsers standardize on this; until then, we have to work around it if we want encapsulated, reusable, and accessible custom form elements.

Labelling elements (like <label> or <fieldset>) and ARIA attributes (aria-label, aria-labelledby, aria-describedby) retain their built-in connections when located in the same DOM as their associated element — connections like the ability to click a label to select a checkbox, or focus on an input to hear the label/description read aloud by a screen reader.

For the <simple-input>, I built in a label that pulls its text from an attribute:

class SimpleInput extends HTMLElement {
  constructor() {
    super();
    const shadow = this.attachShadow({
      mode: 'open'
    });

    const label = document.createElement('label');
    const labelText = document.createElement('span');
    labelText.classList.add('label-text');
    // get text
    labelText.textContent = this.getAttribute('label');

    const input = document.createElement('input');

    // set default value, if any
    if (this.hasAttribute('value')) {
      let val = this.getAttribute('value');
      if (val) input.value = val;
    }

    // check for required attr
    if (this.hasAttribute('required')) {
      // set corresponding input property
      input.required = true;
      // by default, the field is invalid until filled in
      this.setAttribute('invalid', true);
      // add a label class
      labelText.classList.add('required');
    }

    const style = document.createElement('style');
    style.textContent = `
      // ...styles go here
    `;

    // add a class to simplify styles, queries
    this.classList.add('field');

    label.appendChild(labelText);
    label.appendChild(input);
    shadow.appendChild(style);
    shadow.appendChild(label);
  }
}

<simple-input
  label="Street Address"
  value="123 Main Street"
></simple-input>

If you’re using a framework like React or Stencil, you can create a reusable functional or stateless component to inject the correct labelling markup into each custom form element; see, for example, Stencil’s Working with Functional Components.

Radio buttons coded as separate web components (and with separate shadow DOMs) won’t act as a single set, even when the child input elements share a name value; checking one won’t impact the others.

In a recent project we worked around this by treating the radio button set as a single element (<simple-radio-set>), which worked well because there’s no use case for a stand-alone radio button. We configured the set’s inputs by writing template logic that looped through a passed array:

this.radio.options = [
  { label: 'Cats', value: 'cats' },
  { label: 'Dogs', value: 'dogs' },
  { label: 'Leopard Geckos', value: 'geckos', default: true }
]

3. Can you programmatically assign focus to each element? #

Unlike their child HTML elements, custom form elements are not programmatically focusable, e.g., myInput.focus(), unless you make them so. This matters, for instance, when errors are found with client-side validation and we need to move focus to the first invalid field.

Adding tabindex to the custom element may seem like a straightforward fix for this, but it creates a few problems. It would add a second focus state to the component: one Tab click to focus the custom element, and the next Tab would focus it’s child HTML element. Disabling focus on the child element would solve that problem, but would also disable any built-in focus-related behavior, like a screen reader announcing the associated label. You’d have to figure out how to add that back.

We can avoid all of that by enabling delegatesFocus, which lets you programmatically set focus on the custom element. As noted in Shadow DOM v1 - Self-Contained Web Components, by Eric Bidelman, delegatesFocus: true:

...expands the focus behavior of elements within a shadow tree. If you click a node inside shadow DOM and the node is not a focusable area, the first focusable area becomes focused. When a node inside shadow DOM gains focus, :focus applies to the host in addition to the focused element.

Eric Bidelman

Shadow DOM v1 - Self-Contained Web Components

Enable it within the attachShadow method:

class SimpleInput extends HTMLElement {
  constructor() {
    super();
    const shadow = this.attachShadow({
      mode: 'open',
      delegatesFocus: true,
    });
    ...
  }
}

4. Do the events you care about bubble from the shadow DOM? #

Using HTML in custom elements lets us take advantage of many built-in events and behaviors, like focus or the click/tap needed to open a select menu, but sometimes we need the UI to react to input or change events, for example, when applying data formatting or switching up which question is asked next based on the user’s answer.

When a child HTML element fires a composed event (and most are composed by default), it will bubble up through the shadow DOM to its custom element parent. So, for example, if you need to format a value on input, you can do that by listening for the input event on your custom element:

class SimpleInput extends HTMLElement {
  constructor() {
    super();
    const shadow = this.attachShadow({
      mode: 'open',
      delegatesFocus: true,
    });
    ...
    this.addEventListener('input', formatValueFn);
    shadow.appendChild(input);
  }
}

For reasons outlined by the WHATWG, change is not composed:

...events like change, submit, or load are not about a 'direct user action' that affects the page as a whole. They are communicating something that changed internally to the event target in question. If that event target is inside a shadow tree, then the fact that it fired such an event is an internal detail of the component, which that component can choose to re-expose or not.

Domenic Denicola, WHATWG member

whatwg/html: input event is composed but change isn't #5453

To use change (or any other event that isn’t composed), you’ll have to manually dispatch a new event that bubbles to the custom element when the value changes:

input.addEventListener('change', (e) => {
  let changeEv = new Event('change', { bubbles: true });
  this.dispatchEvent(changeEv);
});

5. Does your form submit with data? #

Not unless you explicitly tell it to. Custom elements need JavaScript and possibly some extra markup to:

Expose each custom element’s value for serialization

And we can do that by listening to events fired by the child elements, like input and change, as the user edits the form.

Earlier I added a value attribute to <simple-input> that sets the child input's default value. By attaching a change listener to the child input, we can keep the input's property and custom element’s attribute in sync:

input.addEventListener('change', (e) => {
  // sync value with attr
  this.setAttribute('value', input.value);

  // dispatch change event that bubbles from the input
  let changeEv = new Event('change', { bubbles: true });
  this.dispatchEvent(changeEv);
});

Later this will simplify serializing the form by exposing the input's current value outside of the shadow DOM.

This is just one example of how to capture this value for serialization. If an attribute doesn’t work for whatever reason, the same basic logic can be used to assign the value to a property on its parent element, or append it to a data object or similar. The gist is that, when it’s time to submit the form, we can efficiently grab these values without having to traverse each custom element’s shadow DOM.

Set up any component-specific client-side validation

Using HTML form elements as the basis of our components lets us take advantage of the Constraint validation API. For example, earlier I marked the address field as required and included logic to render the same attribute on its child input:

<simple-input
  label='Street Address'
  value='123 Main Street'
  required
></simple-input>

We can then add methods to the component definition for altering the input when invalid (or restored to a valid state). In this case, I’m conditionally toggling an invalid attribute on the custom element along with error messaging and a class on the input:

this.isInvalid = () => {
  this.setAttribute('invalid', true);
  errorMssg.textContent = 'Please enter a value.';
  input.classList.add('invalid');
};

this.isValid = () => {
  this.removeAttribute('invalid');
  errorMssg.textContent = '';
  input.classList.remove('invalid');
};

Then listen for the blur event to test the input's validity property and call the appropriate method:

input.addEventListener('blur', (e) => {
  // client-side validation
  if (input.validity.valueMissing) {
    this.isInvalid();
  } else {
    this.isValid();
  }
});

Make sure your submit button submits

Our goal is to ensure form submission is handled by JavaScript in a way that mimics a <button type='submit'>. By default, a standard HTML submit button fires two events in succession on the associated form:

1. submit, which kicks off form submission and triggers the browser to run any built-in validation (e.g., contains inputs marked required).
2. formdata, is fired when validation passes and data entries are appended to the FormData object.

One might assume we could just bind a submit() event to our custom button and be done with it — but no. Calling simpleForm.submit() does not actually fire the submit event. The submit event only fires when called by an HTML button or submit input. However, it does go ahead and fire the formdata event, possibly with no data attached. This is all perfectly fine.

The requestSubmit event was created to solve this problem, and it accurately mimics button behavior when simpleForm.requestSubmit() is called. Unfortunately, versions of Safari pre-16 don’t support it. (You can try it out now in Safari 16 beta.)

Use an HTML submit button

Until Safari 16 is more ubiquitous, I prefer to sidestep the custom element/JavaScript event issues altogether and use HTML:

<form id='important-data'>
  ...custom form elements...
  <button type='submit'>
</form>

Then attach a submit listener to the form for processing client-side validation and creating a FormData object.

If your project must use a custom button element, you can include logic in its component definition that injects a hidden <button type='submit'> into the light DOM. You can then trigger a click on the HTML button and listen for the submit event.

Put it all together

To wrap up the simple-input example, the accompanying form logic might look like this (also on CodePen):

const simpleForm = document.getElementById('simple-form');

simpleForm.addEventListener('submit', (e) => {
  // pause to allow validation
  e.preventDefault();

  let invalidFields = simpleForm.querySelectorAll('[invalid]');

  if (invalidFields.length > 0) {
    invalidFields.forEach((field) => {
      // apply styles
      field.isInvalid();
    })
    // focus the first invalid field
    invalidFields[0].focus();
  } else {
    // create a FormData obj
    this.simpleData = new FormData(simpleForm);

    let fields = simpleForm.querySelectorAll('.field');
    fields.forEach((field) => {
      // add each label/value pair to the FormData obj
      // the `set` method adds new or replaces existing values
      // https://developer.mozilla.org/en-US/docs/Web/API/FormData/set
      let name = field.getAttribute('label');
      let val = field.getAttribute('value');
      this.simpleData.set(name, val);
    });

    // at this point you can package and send your data in a few ways, more here:
    // https://developer.mozilla.org/en-US/docs/Web/API/FormData/Using_FormData_Objects
    // replace the following with submission logic :)
    let feedbackArr = [];
    for (let [name, value] of this.simpleData) {
      feedbackArr.push(`${name}: ${value}`);
    }
    feedback.innerHTML = `<h3>Form values submitted:</h3>` + feedbackArr.join(', ');
  }
});

To recap the form logic:

• I’m double-checking validation at the form level. All required fields were assigned an invalid attribute by default, so if they were skipped (never triggered blur) or failed the internal validity check, they’ll be flagged. I also assign focus to the first invalid field so the user can correct the error and try again.
• When all fields pass, we can append their values to a FormData object, by either creating a new object or using an existing form's object.

Resources linked in this post #

• 6 Reasons You Should Use Native Web Components, by Kai Wedekind
• Shadow DOM v1 - Self-Contained Web Components, by Eric Bidelman
• MDN: ElementInternals
• calebdwilliams/element-internals-polyfill
• MDN: is attribute
• Lion web component library, authored by ING
• Shoelace web component library, authored by Cory LaViska
• MDN: :focus-within
• Can I Use Accessibility Object Model (AOM)
• A complete guide on shadow DOM and event propagation, by Pierre-Marie Dartus
• input event is composed but change isn’t #5453
• Stencil documentation: Events
• MDN: Constraint validation API
• MDN: ValidityState
• MDN: Using FormData Objects
• MDN: HTMLFormElement.requestSubmit()
• The Anatomy of Accessible Forms: Error Messages, by Raghavendra Satish Peri
• MDN: ShadowRoot.delegatesFocus

In 1998, I went to college and was peer pressured to use Netscape by my roommates. Netscape had an exciting atmosphere about it, and its move to open source turned fellow Computer Science nerds into gleeful converts. That move to open source would be a critical change in the life of Netscape but also in the life of the Web and in the story of Internet Explorer.

In 2000, I used my student discount to get a copy of FrontPage 98. FrontPage had all these cool DHTML effects like “glow” using proprietary ActiveX controls. I liked the effects so much, I switched back to using Internet Explorer 5. The year 2001 would bring us IE6 on Windows XP with a brand new aesthetic that made Netscape feel ancient. During these years I built websites for college groups like my ultimate frisbee team and was blissfully ignorant of the fact that they didn’t work the same in non-IE browsers. This is some foreshadowing of the problems with IE’s monopoly.

In 2003, I saved enough money through my first fulltime job to buy my first Macbook Pro. OS X 10.1 was new at the time and Safari didn’t exist yet so I used Internet Explorer 5.5, which took the “Aqua” aesthetic to heart and had a cool feature that would ping a list of your favorite sites to check for updates; a weird precursor to RSS. Later in 2003, Apple released Safari and —Apple fanboy that I was— I switched to that.

In 2006, I started doing web development as a job. I read Zeldman’s Designing for Web Standards and became passionate about web standards. IE6, in a web of web standards, earned a bit of a bad rap among developers due to its bespoke box model and lack of updates (compared to Firefox, Safari, and soon Chrome). IE7 did come out, then IE8. Each one better than the one before but still with their own quirks that left them with a bad feeling. IE became the butt of every conference joke. “What about IE?” became the bane of every person talking about new web features. We put “Upgrade your browser” or “Try Firefox” banners on our sites. We collectively tried to eradicate it.

In 2011, Nishant Kothary invited Jason Santa Maria, Frank Chrimero, Naz Hamid, and Paravel to work on a project called “Lost World’s Fairs” to celebrate the launch of IE9 and highlight its newfound support of WOFF web fonts. A celebration of the Web and what browsers can do. IE9 was a massive improvement and it seemed like the gears of change were turning. For sure one of the funnest projects I’ve ever worked on where I got to flex my skills.

In 2012, in part due to the work on the Lost World’s Fair site, Paravel was able to work on the Microsoft.com homepage, right around the launch of Windows 8 (featuring the short-lived Internet Explorer 10). Gruber liked it and I heard Steve Ballmer himself gave it a thumbs up. Pretty cool.

In 2015, I switched back to Windows for #davegoeswindows. Part of the unpaid deal was to try and use Edge, the successor to IE, as my daily browser. It’s still impressive what the original Edge team did in an attempt to salvage a browser and its reputation. Pivoting from the old Trident rendering engine to EdgeHTML, rearchitecting its security principles, and building something modern and fast. There were leftover IE bits in Edge (e.g., F12 Developer Tools), but I got used to it and experienced using “not the most cutting edge” browser as my daily driver. The #davegoeswindows experiment was one of the most educational stunts I’ve ever done.

This week on June 15th, 2022, Internet Explorer reached its end of life and is no longer supported by Microsoft. I think this is something to celebrate. It’s the end of non-evergreen browsers. While “Evergreen” does not mean immediately available and saying “IE is dead” doesn’t mean someone out there isn’t using it, my hope is those people don’t become a gigantic strawman like “the boss who uses IE” did. It’s important to celebrate that outdated software licenses for governments and enterprise IT departments forcing legacy browser usage no longer control our industry or our collective conscious. That is life-changing.

Internet Explorer has been a part of my entire online life; equal parts thrill, shame, joy, and pain… well, a smidge more pain. Over the years, IE crossed the boundaries from being a tech beacon (the first browsers with CSS), to becoming a villain we all raged against, to becoming a technical liability. The full circle. Hearing IE jokes from late night talk show hosts is surreal and noteworthy; IE sits in the cultural seat for a public roasting, the razzing of an old friend, the popularity of a celebrity death.

Though I may sound sentimental, I’m happy to say goodbye. I already feel the new allocations as sections of my brain used for remembering browser quirks get garbage collected. And in some ironic twist… the browser I’m reading this article on today is a browser from Microsoft. The spiritual successor to that old friend and foe. While IE is dead, its legacy lives on.

Standups are a great tool for sharing visibility. Unfortunately, not everyone loves standups. I’ve personally experienced some extremely toxic scrum master situations. Impersonal bots can have the same effect. A daily status report can feel like micromangement leading to a loss of autonomy. Also, that visibility into your work evaporates after attendees leave the call.

For the past four or five years, I’ve been practicing an alternative to daily standups. Rather than waiting for people to confront you, I find it better to proactively share your progress in a brief bulleted list¹ in a public channel (of appropriate level). That’s the secret: share without being asked. The template has evolved a bit over the years, but here’s what it looks like now:

💪 **Progress**
- Fixed something project#123
- Added something project#234
- Documented something

😖 **Regressions**
- Found bug on something project#345

🧪 **Prototypes**
- Experimented with new feature codepen.io/123

💬 **To Discuss**
- Blocked on something project#456
 
📆 **This Week**
- Work on new feature project#567
- Out of office on Friday

That’s a … uh … standup?

Yeah. It’s basically a standup in newsletter form. It could be the years working in a Japanese office talking, but I don’t hate standups. They are great for mind-melding. But, as I’ve experienced, not everyone thrives in standups. But the sharing part is valuable, I try to keep doing the sharing part.

I’ve done this in solo contexts, team contexts, and external client-facing contexts and no one hates it. No one says, “God, Dave, I wish you’d quit summarizing what’s going on.” No one asks for it, I just post it. People —especially those that pay you— enjoy seeing progress made and you (or your team) can avoid a lot of workplace mistrust issues by broadcasting a short progress report.

Consistency helps. Any weekday works but I’ve found posting on Monday mornings provides a nice recap of last week’s progress and sets a baseline for expectations in the upcoming week. It’s also a good opportunity to publicly celebrate specific people or any team wins as well.

Thus sums up my entire software development philosophy: Proactively communicate as succinctly as possible what you’re working on, what problems you ran into, and what you’re working on next.

I'd seen this before and suspected that the game couldn't be loaded due to corruption during boot (on the GB side). I was wrong, but I definitely enjoyed the challenge!

Opening up the Gameboy up and took a peek, and yep, found game pak loading doberry had been messed with. Bit of a duff job on whoever tried to repair it before me - and it even looks like they spotted there was a short and tried to slice through it with a knife:

Pins A2 and A1 were definitely connected! Some flux and solder later and it looks more like this:

And now the Gameboy boots with a nice clean Nintendo logo. Except… it doesn't go past that point at all - and in fact the screen looks like it's doing some weird flash dance, going between dim and off (and I could see the amperage being pulled was fluctuating and not steady). On top of which, I'd also noticed I hadn't heard the speaker.

Fixed (replaced) the speaker first - it had no continuity between the two pins at all, so the only spare I had was this bigger one, but now I had sound again (but loading isn't working still):

Under the microscope I found there was corrosion (possibly it was dropped in liquid, my best guess), around the contrast wheel. After I tried to clean it, two of the five pads completely removed themselves from the PCB and I started noticing more corrosion across the board.

The far left and middle trace pads were completely removed. To (sort of) fix the contrast wheel, according the to schematics, I could jump the far left pins together, and then the next pins together.

Still didn't work though. So search again under the microscope and came across this via with all it's copper gone (on the far right)

You can also see some residue green around some of the vias from corrosion.

I traced this line and it joined the S-RAM to the cartridge slot and then back to the CPU, and from the underside of the board, where the via was missing the copper - there was no continuity between the two chips - when there definitely needed to be.

So jumper to the rescue (I had to use a spare resistor lead as a jumper, turns out all my wires were too fat!):

And after that rather dodgy soldering job - the Gameboy Pocket is back to life!

Now I've just got to find it a new home (I've already got too many Gameboys!)

Originally published on Remy Sharp's b:log