Closed dontcallmedom closed 2 years ago
I've been meaning for a year to draft a proposal for a more nuanced approach to this complicated issue. A few random thoughts:
{{SeeCompatTable}}
with something like {{showStatus('Spec Name')}}
. It would print a blurb based on the status
field in SpecData.json
.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) The BCD definition is written down here: https://github.com/mdn/browser-compat-data/blob/master/schemas/compat-data-schema.md#status-information
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. Different vendors might also have different ideas about the maturity of specs or what is a "trial" implementation vs a "real" implementation. I think to avoid misguidance, we should drop the "experimental" status from BCD and remove all banners from MDN, so we're out of this game. Web developers will still be provided with a compat table with implementation status and links to the feature's specs but they will have to make a call from this information themselves.
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.
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.
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 experimental
status on BCD.
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.
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.
+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)
+1 on removing them
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 https://groups.google.com/forum/#!topic/mozilla.dev.developer-tools/U350YHcJZac
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.
I don't expect experimental
to go away any time soon, but following extensive discussion on https://github.com/mdn/browser-compat-data/issues/6905, we have taken steps to clarify the definition of experimental (and provide additional data guidelines) such that it does not depend on the specification. From now on, setting experimental
to true
or false
will depend only on whether (and, in some limited ways, how) browsers are shipping a feature.
The just-merged https://github.com/mdn/browser-compat-data/pull/9933 contains the changes in question.
While we're not close to eliminating experimental
, I believe we've taken a big step toward making experimental
more meaningful, useful, and maintainable.
Can a linter be implemented for that theoretically?
Parts of it would be straightforward, I think. For example, preventing experimental
being true
for features implemented in multiple engines (unprefixed, unflagged) wouldn't be too complex. But ensuring all the cases are correct would be somewhat more difficult (e.g., the "may expire" escape hatch might depend on a human interpretation of flagged features).
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:
experimental
is true and deprecated
is falseexperimental
and deprecated
are falseexperimental
is false and deprecated
is truehttps://github.com/mdn/browser-compat-data/pull/6813 will disallow the 4th possible state.
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.experimental
to only mean the second item, or eliminate it completely if that case is not very frequent.