mdn
Mark features with one engine support 'experimental'
Similar to https://github.com/mdn/browser-compat-data/pull/17357
Summary
These features are supported by only one engine, so should be marked as 'experimental'.
Supporting details
https://github.com/mdn/content/pull/19569#pullrequestreview-1072232578
cc/ @teoli2003
(Note we are synchronizing, with a script, what is displayed on MDN and what is in bcd. One day it will be displayed automatically but we had 100s of errors so it was really needed).
On the BCD side, we typically say that a feature that has been in one browser for a long period of time should be considered non-experimental, but what do you guys think about that?
I used dialed down version the test-status.ts#checkExperimental() to find these. If we consider flags, prefixes, and alternative names then there will be ~316 files modified in the entire repo.
On top of what @queengooborg said, the yarn fix is non functional at the moment, so this "one engine = experimental" is not being enforced strictly. If we mark the old features experimental then people may come complaining.
@queengooborg What about features that are old but still behind flags? For example:
- https://developer.mozilla.org/en-US/docs/Web/API/AmbientLightSensor
- https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/commit There are ~9 such cases.
What about features that are old but still behind prefixes? For example:
- https://developer.mozilla.org/en-US/docs/Web/API/SpeechRecognition There are ~11 such cases.
What about same for alternate names? For example:
- https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent/replacesClientId There are ~10 such cases.
I used dialed down version the test-status.ts#checkExperimental() to find these. If we consider flags, prefixes, and alternative names then there will be ~316 files modified in the entire repo.
The function isn't a fully-developed function to decide experimental status -- it's actually only used to set experimental to false, but not to true. My goal is to automate both experimental and standard track status, so that contributors do not have to manually update them!
We have the full breakdown of when to set experimental to true or false in the data guidelines here: https://github.com/mdn/browser-compat-data/blob/main/docs/data-guidelines.md#choosing-an-experimental-status
The function isn't a fully-developed function to decide experimental status -- it's actually only used to set experimental to false, but not to true. My goal is to automate both experimental and standard track status, so that contributors do not have to manually update them!
I think we'll have to involve git history in the script. 🤔
We have the full breakdown of when to set experimental to true or false in the data guidelines here...
If you guys terminate this PR, I'll update the statuses on mdn/content side.
For the special cases mentioned above I've created following PRs:
- https://github.com/mdn/browser-compat-data/pull/17402
- https://github.com/mdn/browser-compat-data/pull/17403
On the BCD side, we typically say that a feature that has been in one browser for a long period of time should be considered non-experimental, but what do you guys think about that?
I think this is a bit problematic. If a browser develops an obscure API that no other vendors is interested in, it will just sit there forever and become non-experimental.
Also, often, for APIs that are the brainchild of one vendor, the first implementation is made by the spec writers. We all know how it goes when there is some internal pressure to release: if the feature works for the purpose, management pushes for its release. When a second vendor implements it later, that's when the actual review of the API happens and where changes are implemented (if still possible). If not possible, a better API is developed and adopted by all vendors, the original API staying in one browser, deprecated, until most users have migrated (or died out).
That's why I think that not marking such APIs as experimental is detrimental to web developers. The risk of change, or event marked as deprecated, is real. When not experimental the web developer assumes that it is safe to consider it stable enough to stay forever on the Web platform. Features implemented by one vendor don't provide this guarantee.
If not possible, a better API is developed and adopted by all vendors, the original API staying in one browser, deprecated, until most users have migrated (or died out).
…Features implemented by one vendor don't provide this guarantee.
I think the best example of this could be: https://bugs.chromium.org/p/chromium/issues/detail?id=695508#c18 Further down the conversation they suggest to use polyfill to stop using the API.
Perhaps you can use the polyfill below to get off the filesystem API?
This pull request has merge conflicts that must be resolved before it can be merged.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This pull request has merge conflicts that must be resolved before it can be merged.
This pull request has merge conflicts that must be resolved before it can be merged.