Here’s a rewritten version of the article with a more concise, narrative-driven tone, while preserving the original ideas and structure:
—
The Joy of Serendipitous Browsing
One of the best parts of diving into web research is how easily you can end up somewhere unexpected. That’s exactly what happened when I started writing an Almanac entry on @namespace—a rarely used, legacy CSS at-rule. There wasn’t much information out there, until I stumbled upon a 2010s blog post by Divya Manian that shed some light on it.
But what really caught my attention wasn’t the post itself—it was the navigation arrows on Divya’s blog. Out of curiosity (or maybe by accident), I clicked the left arrow twice and landed on another post titled “Notes from HTML5 Readiness Hacking.”
Rediscovering HTML5 Readiness
That detour led me to revisit HTML5 Readiness, a project by Paul Irish and Divya Manian. It visualized browser support for cutting-edge web features like media queries, transitions, and the video/audio elements using a colorful, growing rainbow.
The project ran from around 2010 to 2013, showcasing data as far back as 2008. Seeing it again was a nostalgia trip—back to a time when SVG support was still spotty. What really struck me was the thought: if this project were updated today, the entire rainbow would be complete.
Introducing: Web Readiness 2025
That inspired me to build something similar for today’s web. So, over a weekend, I created Web Readiness 2025—a modern take on the HTML5 Readiness concept, tracking upcoming HTML and CSS features I’m excited about.
You can check it out at webreadiness.com. Right now, it’s a bit sparse, but the idea is to watch the rainbow grow as browser support improves.
Sourcing the Data
My initial idea was to use the
But for this project, I needed something more scalable. Instead, I pulled data directly from the Web Features API (https://api.webstatus.dev/v1/features/) and used the GitHub repo to find all available features.
Building With Web Components
I also wanted to learn more about Web Components. Inspired by Geoff’s notes on Scott Jehl’s Web Components Demystified course, I made each “ray” in the rainbow a custom web component.
Each ray:
– Reads its feature ID from a data attribute
– Fetches data from the API
– Displays browser support as a list
Here’s a simplified version of the component:
class BaselineRay extends HTMLElement {
constructor() {
super();
}
static get observedAttributes() {
return [“data-feature”];
}
attributeChangedCallback(property, oldValue, newValue) {
if (oldValue !== newValue) {
this[property] = newValue;
}
}
async connectedCallback() {
// Fetch and display feature data
}
}
customElements.define(“baseline-ray”, BaselineRay);
Animating the Interface
Design isn’t my strongest suit, so I leaned on animation to bring the interface to life. I started with simple keyframe animations for the page load. For toggling between rainbow and list views—something driven by user interaction—I used the Web Animation API instead of Same-Document View Transitions, which proved more complex than expected.
Handling Layout with sibling-index() and sibling-count()
To position each ray in a semicircle, I needed to know its index and the total number of siblings. While CSS functions like sibling-index() and sibling-count() are on the horizon, they’re not widely supported yet.
So I used JavaScript to simulate them, assigning custom properties like –sibling-index and –sibling-count. That allowed me to rotate and space each ray correctly using CSS:
baseline-ray ul {
–position: calc(180 / var(–sibling-count) * var(–sibling-index) – 90);
–rotation: calc(var(–position) * 1deg);
transform: translateX(-50%) rotate(var(–rotation)) translateY(var(–ray-separation));
transform-origin: bottom center;
}
JavaScript-Free Hover Effects with :has()
One cool trick I used was the :has() selector. When you hover over a browser name in the caption, the corresponding ray in the rainbow highlights—without a single line of JavaScript.
Even though the caption and rainbow aren’t directly related in the DOM, :has() lets me style a parent based on its child’s hover state, making this interaction seamless and performant.
What’s Next?
Now, we wait. I hope Web Readiness becomes a place people can revisit to see how
