Small features as a focus area for Interop 2023?

[domenic]

Hi all,

I'm wondering if there is interest, for Interop 2023, in increasing the scope to focus on small, new features that address developer pain points. In particular I suspect there are many web platform improvements which have developer demand, and are not particularly controversial or hard to implement, but have just fallen through the cracks. (I've been calling these "papercuts".) Some examples, roughly in order of smaller to larger:

• Static text encoding/decoding functions
• A promise-returning version of setTimeout
• A way of opening <dialog> elements without JavaScript
• AbortSignal.any()
• Full CSS attr() support
• A way of setting headers on EventSource
• Observables

Work on features like these would be different from the existing test-based focus areas, or the investigation efforts. They would involve writing the spec (usually), writing the tests, and implementing. Unlike the investigation areas, the goal here would be to find features that are small enough that within a year they could go through that entire process. Then we could all have celebratory moments like "finally, every browser has shipped a promise-returning setTimeout!".

If there were interest in this, I think we'd want to involve web developers in the feature-selection process, to ensure we're getting the best bang for our buck. Web developer input already factors in indirectly, e.g. how some browsers prioritized features from Interop 2022 based on surveys like the State of CSS. But for these sorts of areas, it might be wise to get more direct input, e.g. in the form of a dedicated papercuts survey, or a stack rank, or upvotes.

What do people think? I'd be happy to attend a meeting to discuss the idea in more detail.

[jensimmons]

Work on features like these would be different from the existing test-based focus areas, or the investigation efforts. They would involve writing the spec (usually), writing the tests, and implementing.

This Interop project, part of Web Platform Tests, is not the venue for:

1. writing specifications, or
2. coordinating the timing of browsers shipping features.

The work of writing specs needs to happen in the appropriate working group, where legal agreements and patent policies protect the ability for browsers to implement new ideas. And where the design of new features can be well considered by the experts in that part of the engine, and deeply integrated into the rest of the engine. I see no reason to route around / undermine those working groups, or create a duplication of efforts.

And there is no group where any of us should be colluding to coordinate roadmaps. Each browser is an independent project, and the teams working on each of those browsers make their own independent decisions about what to implement and ship when.

Interop 2022, 2023, etc is a place to come together to choose areas of focus where we believe better interoperability will help web developers and therefore people who use the web. We pull together a set of tests to help browser engineers find needs and bugs. We do some investigation to figure out how tests could work better in the future; and/or to manually test whether or not there is interoperability. That's it.

I'm wondering if there is interest, for Interop 2023, in increasing the scope to focus on small, new features that address developer pain points. In particular I suspect there are many web platform improvements which have developer demand, and are not particularly controversial or hard to implement, but have just fallen through the cracks. (I've been calling these "papercuts".)

Yes, of course. There's no reason to not propose "small" features that are particularly painful for web developers. That is in scope for what we do. We don't have to change the process to include such ideas. We already have many examples of "small" features/bugs that are part of Interop 2021 and 2022. They are simply grouped into categories to make it easier to understand the overall score.

Start keeping a list of such items, and propose each one of them separately when the call for ideas opens up this fall.

[jgraham]

I'm very reluctant to include items which don't have any spec text, except as possible "investigate" areas. Even in that case I'd prefer to focus on areas where we have some legacy implementations, but lack interop and don't have a clear way to get there.

Although we might believe that something is small and therefore trivial enough to specify that specification and implementation in a single year is plausible, it often turns out that there are unexpected difficulties, or disagreements about the correct tradeoffs. Meanwhile, if the thing really is trivial to specify it should be easy to do that work and propose the implementation as part of a future Interop metric. I don't think we want to create pressure on standards orgs to accept low-quality features because we've decided to put them into a public metric without prior agreement (in the form of a specification) about the technical details.

So whilst I'm very happy to have "focus areas" that are groups of smaller features that are not on their own large enough to warrant a full focus area, I expect to still require that any feature in a focus area already has broadly agreed specification text (per the relevant standards org's process) at the time it's selected.

[foolip]

To summarize the conclusion from #90. We have two kinds of proposals planned for Interop 2023. Focus areas are based on tests, where a spec already exist. And investigation efforts are based on completing a set of tasks, which could include working inside the W3C or WHATWG to fix some spec issues, or to write tests, but the score isn't based on the test results.

While we have these two kinds of proposals, there wasn't consensus for combining them, to commit to passing tests that don't yet exist, where the detailed spec text also doesn't exist yet.

I wish I had a good recommendation for how to approach small features, since coordinating on getting them spec'd, tested and shipped would achieve the same outcome faster but without more (likely less) work in total. But I think my only suggestion is to prioritize spec and test work and make it a regular proposal.