Allow overlapping compat keys - #4034
Open
ddbeck wants to merge 2 commits into
Open
Conversation
ddbeck
added
the
minor version required
github-actions
Bot
added
documentation
ddbeck
force-pushed
the
overlap-compat-keys
branch
4 times, most recently
from
May 18, 2026 12:23
25832e1 to
55e55d1
Compare
ddbeck
force-pushed
the
overlap-compat-keys
branch
from
May 18, 2026 12:25
55e55d1 to
e473578
Compare
foolip
reviewed
May 26, 2026
Co-authored-by: Philip Jägenstedt <philip@foolip.org>
| @@ -0,0 +1,54 @@ | |||
| - features: | |||
Contributor
There was a problem hiding this comment.
We have an allowlist for specs that aren't really specs, and in it, we have comments for why we need them.
Could we do the same here? I feel like this would bring a lot of value over time.
Collaborator
Author
There was a problem hiding this comment.
@captainbrosset yes, this is a good idea. Would a high-level comment field work for you, something like this?
Suggested change
| - features: | |
| - reason: "The `<audio>` and `<video>` elements share the `HTMLMediaInterface`, unlike most other elements' interfaces (e.g., `HTMLDivElement` is exclusive to `<div>` elements)." | |
| features: |
Or are you expecting that we would justify each feature ID and key individually, with a more deeply nested structure?
Contributor
There was a problem hiding this comment.
A high-level comment works for me!
ddbeck
commented
Aug 6, 2026
|
|
||
| - No feature has any claim to being first and the shared interface does not represent a useful feature on its own. | ||
| This sometimes happens when two features share a common interface. | ||
| For example, the `HTMLMediaElement` interface is required for both the `<video>` and `<audio>` elements, but there's no application for the `HTMLMediaElement` alone. |
Collaborator
Author
There was a problem hiding this comment.
Suggested change
| For example, the `HTMLMediaElement` interface is required for both the `<video>` and `<audio>` elements, but there's no application for the `HTMLMediaElement` alone. | |
| For example, the `HTMLMediaElement` interface is required for both the `<video>` and `<audio>` elements, but there's no application for the `HTMLMediaElement` interface alone. |
| @@ -0,0 +1,54 @@ | |||
| - features: | |||
Collaborator
Author
There was a problem hiding this comment.
@captainbrosset yes, this is a good idea. Would a high-level comment field work for you, something like this?
Suggested change
| - features: | |
| - reason: "The `<audio>` and `<video>` elements share the `HTMLMediaInterface`, unlike most other elements' interfaces (e.g., `HTMLDivElement` is exclusive to `<div>` elements)." | |
| features: |
Or are you expecting that we would justify each feature ID and key individually, with a more deeply nested structure?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Towards #1173 and a prerequisite to feature merging.
This PR allows authors to allow BCD keys to be shared between features, by adding them to an allow list. It provides guidelines for when to do this (rarely) and demonstrates it by resolving one of the commented cases where we wished to do this.
This PR is not strictly breaking, but we should announce it in the upcoming changes discussion thread and emphasize this change in the release notes.