mdn
Allow standard-track sub-features without implementation / intent to implement
What type of issue is this?
Other
What information was incorrect, unhelpful, or incomplete?
As per BCD's data guidelines, we don't add browser features without any implementation, unless there is clear intent to implement.
However, there is some evidence that this practice can be confusing for end-users:
- https://github.com/mdn/browser-compat-data/pull/25081#issuecomment-2480492583
- https://github.com/mdn/browser-compat-data/issues/25916#issue-2852012266
What browsers does this problem apply to, if applicable?
No response
What did you expect to see?
I would suggest to accept standard-track sub-features, even if there is no implementation and no intent to implement.
Did you test this? If so, how?
n/a
Can you link to any release notes, bugs, pull requests, or MDN pages related to this?
No response
Do you have anything more you want to share?
No response
MDN URL
No response
MDN metadata
No response
The reason we didn't allow features with no intent to implement so far is basically that this lead to inclusion of quite a lot of "specification fiction" features in the past. Often these features would get removed or renamed in the specs again making them even more irrelevant and unstable as they are just ideas at this stage basically.
What would help, I think, would be to land https://github.com/mdn/browser-compat-data/pull/23958 and to require valid deep spec_urls for features that just exist in specifications and with no implementation, so that there is at least a way to know when specs have decided to rename or remove the feature idea again and thus avoiding having dated ideas in BCD.
