Here are some of the features I reached for without hesitation in 2023. It was a good year for front-end web development. Major browsers have been implementing new features at a decent pace, semantic HTML elements with native methods have had some big wins, and CSS is exploding with good new syntax and features.

Some of these are truly new; some are just new to me.

The dialog element

Other items on this list may be more exciting, but none saved me as much time or headache as the native HTML <dialog>. Browser support is about 96%, and there is a polyfill from Google that works if you need to support others. It essentially creates a pop-up with built-in open and close methods. It opens on the top layer and it can be opened as modal, meaning it traps keyboard focus and renders the rest of the document below it inert. It takes a little bit of work to confirm that it’s fully accessible, but compared to writing your own JavaScript-heavy component, it’s a huge win.

I used it a lot in the redesign of the US Holocaust Memorial Museum’s Collections Search detail pages.

Check out the MDN article on it—there is more to it, including built-in ways to return form data to the main document.

Container units and container queries

Now this one truly is exciting. The features front-end devs had been waiting for finally landed in all browsers in 2023 and is changing how we can design and build components: on the basis of their container’s size rather than the container of the whole viewport. I wrote about it earlier in the year and won’t repeat the details here. I think developers are still discovering all the use cases for container queries and units. As Chris Coyier recently observed, “every container queries demo is a card”—and indeed that’s how I’ve used them!. Perhaps 2024 will see that expand into new areas.

In 2023, I put container queries to use in the museum’s reimagining of the History Unfolded website and refreshing of the Experiencing HIstory homepage.

Summary / details

The <summary> and <details> elements are not new but they appeared a lot in my work this past year. At base they are a semantic, browser-native way to show and hide text without having to worry about the event handlers or accessibility. The native UI is simple, like this:

With some CSS and JavaScript flourishes they can be animated and styled however they need to be. I made good use of them in the Collections Search site; the refactored main museum site uses styled and animated summary / details to pull off the accordion UI of the secondary section navigation menus.

Subgrid

I’d bumped into the use case for subgrid many times before finally wrapping my head around it in 2023. Here’s the situation: you have a grid layout to place, say, article summaries across the page. The summaries have a photo, title, short blurb, and call to action link. The main grid layout ensures that the summaries flow in an intrinsically responsive way into rows and columns depending on the screen size. That’s nice, but some article titles are one line while others are three; some blurbs are long while others are short. The sections within each article summary (each grid cell) don’t line up with each other. It looks off.

I used to mitigate the issue using flexbox to distribute the empty space in each subsection in a balanced way, but without subgrid there is no way (without heavy-handed JavaScript and resize observers) to make the length of one article’s blurb affect the space reserved for the others. That’s what subgrid does: it allows grid items to have grid tracks that are defined by the parent grid.

Check out the MDN subgrid article for more. It took me some time to understand that the number of grid tracks for the main grid needs to equal the total number of subtracks. The children of the main grid are then set to span multiple tracks. My initial assumption was that I’d be dividing main tracks into subtracks when in fact it’s more like grouping subtracks into main ones.

My hopes for 2024

Here are some of the features I hope to use in 2024 that I have not yet

Web components

My work’s websites span a number of different tech stacks. The newest is a Nuxt/Vue build with Contentful for the headless CMS. There’s a Ruby on Rails site and several Laravel sites. We’re working to consolidate the design language across sites, which is good, but the code isn’t portable from one to another. Web components could help with that. Some of our tech stacks are old enough that using web components might trip things up, but in theory web components would make framework-agnostic elements that we could use across our sites.

okclh colorspace

Browser support for okclh() is at 88% based on global usage. That’s not quite high enough to use without a fallback, but I hope 2024 is the year I get to use it in production, straight up or with a postprocessor. Why? First colorspace can describe colors beyond the typical sRGB gamut, so on hardware that supports a wider gamut you can use okclh() to make colors you haven’t been able to make before. Second, like hsl(), the definition of colors is more intuitive, allowing you to set the lightness, chroma (similar to saturation), and hue of a color in a way that mirrors how we think about color. Unlike hsl(), though, the lightness of a color in okclh() is perceptually consistent, meaning that colors with the same lightness value will look to us to have the same lightness/darkness no matter what hue or chroma they have.

Auto image sizes

I wrote earlier in 2023 that auto image sizes, by the attribute sizes=auto, will “greatly simplify providing the right size native image for the target display size and resolution.” At the time, the WHATWG had just adopted the feature in the HTML standard. Since then, the Chrome team has made progress implementing it; from what I can tell, it should be implemented behind an experimental flag in Chrome Canary soon.

Currently developers have to instruct browsers which image source is the right size/resolution to choose from a srcset. That’s because browsers need to get the image before the layout is calculated. Lazy-loaded images, however, are fetched after the page layout is rendered, so the browser ought to be able to select the best image source for the current layout, screen resolution, and (I hope) network conditions without manual intervention. It looks like auto will be the default value, too.

That, indeed, would make for a very happy new year! 🎉 🥂