Tracking all features, including those that have negative vendor standards positions

[captainbrosset]

This was discussed during today's WebDX CG meeting (notes).

Proposal: create feedback issues on this repo for all features in web-features. Currently, only those that don't have a negative vendor standards position have a corresponding feedback issue.

Summary of the WebDX CG discussion:

• Core question being debated:

  • Should the repository also create issues for features that have negative vendor positions?

  • In other words, is it valuable, or risky, to collect developer feedback and use cases for features that browsers have already expressed opposition to?

• Arguments for including negatively positioned features:

  • Negative positions are often about the specific proposed solution, not the underlying use case. Collecting feedback could help surface unmet needs and inform alternative solutions.

  • The repo has evolved beyond simple upvotes. It now receives thoughful qualitative feedback, making it more useful than originally anticipated.

  • Developers may reasonably ask why feedback is not being collected on these features at all. Excluding these features risks hiding information from developers.

  • Prior examples (e.g. JPEG XL) show that even contentious issues can provide useful signal during decision-making.

• Arguments against including them:

  • The original reasons for exclusion still apply, including that vendor objections are often nuanced and not easily summarized/explained to developers.

  • Web-features and developer-signals are tied to specific solution proposals. But standard positions are about whether something is a good idea at all. Mixing the two things is risky.

  • High likelihood of noise and heated debate, especially for contentious features.

  • JPEG XL is seen as an exception, not a model. Strong demand was already known. Feedback did not help resolve the core blocking issues.

[captainbrosset]

My proposal:

• Open feedback issues for all features, whatever the vendor position.
• If there's a negative vendor position, the issue should link to it, and clearly state that the feature is unlikely to ship in its current form.
• The issue does not summarize, interpret, or justify the position. It only links to it.
• The issue description explicitly mentions that the goal is to collect use‑cases, not advocacy or discussion about a vendor decision. Any out of scope comments will be closed.

[jakearchibald]

• Developers may reasonably ask why feedback is not being collected on these features at all. Excluding these features risks hiding information from developers.

Has this happened?

• The issue does not summarize, interpret, or justify the position. It only links to it.

I worry that, if Chrome's translation API was included, it would show that Mozilla is opposed, and that would be interpreted as blocking nice things that developers want. Whereas in reality, the API has severe security issues for common use-cases.

[captainbrosset]

@jakearchibald

Has this happened?

Yes, see https://floss.social/@bart/115734736441916782 and #375 (comment).

By the way, #375 was an earlier proposal to create locked issues for features with negative standards positions.

I'd also like to highlight this isue 8 comment:

I think developer signals should be independent of browser signals, rather than overridden by negative browser signals.

which I agree with.

[captainbrosset]

I worry that, if Chrome's translation API was included, it would show that Mozilla is opposed, and that would be interpreted as blocking nice things that developers want. Whereas in reality, the API has mozilla/standards-positions#1015 (comment).

We could surface the concerns: labels to give a more complete picture. For example, mozilla/standards-positions#477 has the label concerns:security. Based on your comment, that label could apply to mozilla/standards-positions#1015 as well.

[dontcallmedom]

How about, for features that have opposition, we use developer signals exclusively to collect illustrations of what developers would want to use the feature for? (rather than collecting expression of support)

(we could automatically remove issue reactions if they're seen as counter-productive to community & consensus building)

[rviscomi]

+1 what @captainbrosset proposed earlier

In general, the value of this repo is that it gives developers a venue to express support for things they want to see become interoperable on the web platform. This is consistent with other related efforts like Interop proposals and State of X surveys, but in a more evergreen format. Just as there's nothing to stop a developer from submitting or engaging with an Interop proposal for a feature with a negative standards position, I believe they should also be able to upvote or comment on that feature's developer-signals issue.

@jakearchibald raised valid concerns about developers misinterpreting a browser's lack of support as them being blockers to progress on the web. I support Patrick's suggestion to note any negative standards positions in the issues and link to the full details as needed. Developers might not have been aware of what the reasoning was, or that there was any opposition at all, so this level of transparency should help a lot.

Since JPEG XL was mentioned, it's worth highlighting that developer signals like these were explicitly mentioned as a factor in Chrome's decision to accept it into Chromium. In fact, the JPEG XL issue is by far the most upvoted feature in this repo and probably the most contentious, but @jakearchibald has done a great job moderating the discussion to keep it on-topic. This has been a good test of our Code of Conduct to keep conversations constructive, so we should be able to do the same for other hot issues.

@dontcallmedom unfortunately AFAIK GitHub doesn't support disabling reactions while keeping comments open, or removing reactions. It seems to be all or nothing.