Remove status.experimental #1528
Comments
|
I've been meaning for a year to draft a proposal for a more nuanced approach to this complicated issue. A few random thoughts:
|
|
So, our current "experimental" guidelines are written down here: https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Remove_Experimental_Macros (changed after the discussion in https://discourse.mozilla.org/t/experimental-banners-in-css-docs/16864 and https://discourse.mozilla.org/t/experimental-banners-in-api-docs/23993) I think maintaining an "experimental" status of web platform features has turned out to be quite impossible for us in BCD and on MDN, as we're not watching spec statuses all the time and it seems to be quite a judgement call when to call what "experimental". We have no timer for these things: when added, the status or the banner don't expire after 2 years or anything like that. What do you think @chrisdavidmills @wbamberg @jpmedley @dontcallmedom ? |
|
I'm hesitant to agree to this, as I think it is quite useful to have a quick banner that shows whether something is experimental or not at the top of an MDN page. But if we are going to keep the experimental status, then we do need to be more vigilant in updating the data. I always remove the experimental banner from the top of a page when it stops being experimental (i.e. two browsers start to support this), but I've been really bad at remembering to change the experimental status in the corresponding BCD entry. And as you say, the reader can quickly infer experimental status from the BCD, and make their own mind up whether to use it. Getting rid fo the banners will be even easier when the signalling tool starts to put the BCD summary banners on the top of the MDN pages. So, yes, after we get the signalling tool. Before that, I'm not so sure. |
Sorry, this is not what the signalling tool is about (it is a feedback tool). Having BCD-sourced banners at the top of MDN references pages has been de-prioritized entirely unfortunately, if that's what you're referring to. Our mechanics to control "experimental" banners are quite limited today and so users complain about them a lot since they often stick around forever. Same is true for regularly updating the |
Crap, well I've totally misunderstood that then. OK, well in that case, I will change my opinion from "yes" to "maybe". I am interested in what others think. |
List of all features marked as "experimental" in BCD for illustration of the problem |
|
+1 on removing them - unmaintained, they're noise rather than signal. If/when a better system comes out (e.g. automated based on BCD data updates), then I think it would be useful to resurface some of that warning. (in particular, I'd be interested in learning why the BCD signalling was deprioritized if this is documented) |
Yes I agree. As you say, a lack of time/tooling to maintain this is only part of the problem. It also seems we're not certain what we intend this to convey or how to determine it, and if we don't understand what we mean, how can our users? It's probably better to provide specific information about potentially unstable interfaces, written by humans in the document itself. |
|
I support either removing or fixing. Without precisely knowing the current state of things, I'm reluctant to say more than that. Have you considered simply loading the data from https://www.specref.org? |
|
Firefox Devtools are using our "experimental" status now. See the screenshot here Before dropping this, we should see if it is useful to users there. I hope we're not misguiding. I'll pass the list of css features that are currently marked as "experimental" to some folks who could judge better than I can. |
|
Perhaps experimental is the wrong thing to say for CSS features that are shipped in browsers. What is probably most useful is a top of the page warning where something is very newly available in browsers, only implemented in one browser. I think in that case reminding them to check the compat table is useful, and that is information we could automate from the BCD with some rules. I get people asking me why my subgrid examples don't work for example, and they are using Chrome. We have things like the logical properties and values which are well implemented in Chrome and Firefox, are not experimental but it is probably worth a new developer being aware that using those properties rather than the physical ones is going to leave out some browsers and all but the newest versions of other browsers. |
|
If I were king for a day, I'd make all developer tools NOT show the experimental status of a spec. Web Payments API changes frequently and is still behind a flag in FF. Yet it's a candidate recommendation. Service workers are in all the major modern browsers and haven't change in years. Yet it's a draft spec. |
5 tasks
3 tasks
|
I don't expect The just-merged #9933 contains the changes in question. While we're not close to eliminating |
|
Can a linter be implemented for that theoretically? |
|
Parts of it would be straightforward, I think. For example, preventing |
|
Given that there is a guideline for this now, should this issue be closed? |
|
Since we have a guideline for this now, and a linter is on the way, I think that we can safely close this issue. We can probably automate this eventually too, but that's a problem for another day! |
|
To summarize where we're going to end up, we will have 3 stages of a feature lifecycle represented by 2 booleans:
#6813 will disallow the 4th possible state. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The definition of what constitutes an experimental feature has two aspects:
At least the first item sounds like it could be automatically derived from the rest of the data. I don't know how often the meaning of the second item is used, but it would probably be worth considering recasting
status.experimentalto only mean the second item, or eliminate it completely if that case is not very frequent.The text was updated successfully, but these errors were encountered: