focus-area-proposal.yml
focus-area-proposal.yml
Name | About | Labels | Assignees |
---|---|---|---|
Focus Area Proposal | Proposal for an Interop 2024 Focus Area | focus-area-proposal |
Thanks for taking the time to make a proposal for Interop 2024!
Be sure to read the requirements and guidance to give your proposal the best chance of success!
Note: If this feature is widely implemented, but lacks a high quality specification or tests, an Investigation Effort may be more appropriate.
When you submit your proposal, a GitHub issue will be created to track it. Please check back on GitHub from time to time to answer any questions we have. You'll also be able to make changes to your proposal from now until October 12 by commenting on your issue. See our README for the full timeline of Interop 2024.
Proposal Details
Brief description of the feature. Try to be clear about what parts of the feature are included and not.
Specification for the feature. The feature must defined by a standards-track specification from one of the following organizations:
- IETF (Standard Track)
- Khronos Group
- TC39 (Stage 2+)
- W3C (Recommendation Track)
- WHATWG
Links to any open standards issues that affect the proposal.
Tests for the feature in web-platform-tests on wpt.fyi.
These are the tests that will be used to score progress in this Focus Area. If the tests are not yet ready, link to evidence of the tests being worked on (e.g. a PR in the web-platform-tests repository or an issue in a vendor bug tracker).
Supporting Evidence
The following fields are for collecting data to assess the likely impact on authors and users of improving interoperability of the proposed feature. It is not required to fill in all (or any) fields, but proposals with stronger supporting evidence are more likely to be selected.
Examples of developers running into the lack of this feature, or problems with the feature, on sites like Stack Overflow.
Developer feedback surveys referencing this feature e.g. for example, MDN surveys, State of CSS or State of JavaScript.
Evidence of existing usage of the feature e.g. Chrome use counters or HTTP Archive, or links to libraries or other code trying to use the feature.
Links to code that's trying to work around the absence of this feature e.g. polyfills.
Information about the impact of the feature on the accessilbility properties of the web platform, if any.
Information about the impact of the feature on the privacy properties of the web platform, if any.
Any other relevant information that will help assess the impact of making the feature more interoperable.