meyerweb.com

The proposal period for Interop 2027 closed in late September, which means the Interop team is now in the process of working through all the proposals and ultimately deciding which will be taken on next year. Part of that process is looking at “developer signals”, which is a loose amalgamation of “State of…” survey results, feedback gathered by developer relations teams, blog posts, YouTube videos, and so on.
A relatively new tool is Jake Archibald’s ranking tool, where anyone with a Github login can add any of the ~150 proposals to a ranking list, then order them in the priority you would give them if the decision were solely yours. The results will be anonymized and shared with the Interop team.
A number of people (like Ana, Declan, Paweł, Sara, Stuart, and Tyler) have blogged about their rankings, and I love a good web standards bandwagon, so here’s my bloggery! And if you’d like to hear me talk about all this, head on over to Igalia Chats to give it a listen. And maybe even a subscribe!
To be crystal clear: these are my personal rankings, and do not predict or even affect how I will vote as Igalia’s representative to Interop. In fact, it’s almost certain that I will, at some point in the process, vote to cut more than one of the things I’ve ranked here, or at least will not vote to advance them to the next step in the process. That’s how Interop goes, given that there are an order of magnitude more proposals than the teams have the resources to accept.
First, let’s go with my Top Five, in order.
You might think I’m picking this one because Igalia has been a large part of getting the standard finished and support into browsers, but I actually ranked it first because it is it just such a huge step forward. I don’t write much JS, but even I know the Date object is terrible. The Temporal API is so much better, it’s hard to overstate. It understands time zones, summer times, and even historical changes like the exact moment a given country changed time zones. I can’t find anything else in the list that I think is more deserving of all-browser all-out effort to implement and make interoperable.
This gets my second-place ranking because it is, to me, the essence of the perfect Interop proposal. In Jake’s ranking tool, the summary for this proposal is literally “Fix remaining test failures.” The proposal itself says “These functions are shipped in all engines, but all have [WPT] failures.” That’s what Interop is for, in my opinion. The thing exists, but needs a bit more work to be truly interoperable.
This proposal gets the bronze medal from me for similar reasons the previous proposal grabbed silver. In this case, we have a long-supported feature that still has a vendor prefix clinging to it. Unprefix it, already!
This one’s emblematic of another role Interop has taken on over the years, which is to get an up-and-coming feature interoperable from the outset. Here, the ability to use HTML attributes to shift how heading levels are treated is already behind flags in two browsers. Having the browser teams agree to all work on the same thing at the same time would help find any problems early, and get them fixed before the feature comes out from behind the flags. I’ll also admit my personal ranking of this is a little bit influenced by the fact that it would help me fix problems on this very web site — indeed, in this very blog post — but it would help a lot of others as well, such as Github.
Okay, I cheated a little here by combining two proposals for this article. In my actual ranking in Jake’s tool, I ranked them #5 and #6, because I think if you’re going to clamp lines, you’re probably also going to want to trim margins. I like the capabilities line-clamping enables (and I’d think that even if Igalia weren’t one of the drivers of its implementation), and I imagine that if you’re limiting an element’s height to a certain number of lines of text, you’re probably trying to make things on the page adhere to a vertical rhythm and you don’t want inner margins possibly messing things up. Maybe I’m off base conflating the two, but it feels right to me.
So there you go, that’s my top five or six rankings. I ended up ranking twenty proposals in all, triggering a friendly “whoooa there, big fella” warning from the ranking tool. Here are the rest of what I put on the list, grouped by high-level area and then sub-sorted in roughly alphabetical order, with exceptions to group like topics together:
That’s where I ended. There were a few I didn’t rank because I’m pretty confident they’re already going to get strong ranking support. There were a few I wanted to rank, but couldn’t in good conscience because they had no standard, no evidence of browser interest, or neither of those. And in all honesty, there were some that didn’t get on my list because I think they’re bad or terribly formed ideas.
How about you — what are your favorites? Go rank them, blog them, and spread the word however you can.
Earlier this month, I returned to CSS Day for the first time since 2018 to deliver my first in-person talk since 2022. “Forging Our Own Paths” should be available at some point; in the meantime, for the six or seven people in my audience who might need to do something similar, I’d like to share a small macOS workflow I developed to make syntax-highlighting code blocks in situ in Keynote a lot simpler. The end result is to have an entry (or entries) in the Services submenu of the contextual (right-click) menu for highlighted text. All this is adapted from an old blog post I found copied in a few places, and which needed some updates to make things work in 2026.
First, install highlight. I used brew install highlight, and the rest of this piece assumes you’ve done it that way. If you install it another way, such that it ends up in a different location than Homebrew would give it, you’ll need to modify a variable value later on, which I’ll point out when we get there.
Next, you need to install the following (also avai