How should we handle removal for features only implemented behind in Nightly/Dev builds?

[queengooborg]

While I was dealing with PositionSensorVRDevice, I noticed that its support was only available in Nightly/Canary build in each browser that supported it. Chrome has already removed WebVR support (https://www.chromestatus.com/features/4532810371039232) as well, so support is only present in Firefox Nightly. Since WebVR is a deprecated standard and was never implemented into any stable release, however, I feel that we should consider it to be irrelevant and remove the associated compatibility data.

CC @ddbeck and @foolip

[queengooborg]

Also CC @jpmedley. Joe, I know you've been talking a lot about not including Chrome flag data in BCD any longer, I wonder if you had an opinion on Canary-only features too!

[foolip]

I think dropped experimental features should be considered irrelevant and removed. No 2 year window like we do for things that reached a stable release.

[lukewarlow]

The "vr" feature policy is in a similar position where it's not relevant as the API was never stable in anything but Firefox and Firefox never implemented that feature policy. (As far as the current data says at least).

[jpmedley]

Also CC @jpmedley. Joe, I know you've been talking a lot about not including Chrome flag data in BCD any longer, I wonder if you had an opinion on Canary-only features too!

I believe that I have only ever advocated for flags to be kept off MDN. (I'm not even allowed to include them in the beta release post.) A former MDN writer always insisted that such features are "part of the platform". They're not. There's no such thing as a "platform flag". There's not even a W3C standard for it. We don't want web sites asking users to flip flags in order to use a site. They're narrowly intended for an individual developer testing a new feature on their own device. They typically occur before origin trials, which aren't allowed on MDN because they're not for established standards. Not all flagged features enter origin trials, but a significant number do, meaning the flagged features are exactly as likely to change implementations as is an origin trial feature. Once a feature is enabled by default, no one should ever use the flag. Since these are on new features, they often apply to features whose ONLY implementation is the test implementation in Chrome. Once a feature is enabled by default,

To summarize:

• When Chrome features are behind a flag, there's rarely a fully enabled version of the feature on the platform in any browser.
• A significant portion of the flags are for features with unstable implementations.
• When there's a fully enabled version of a flagged feature on the platform, the flag shouldn't be used.

The current standard, I believe is to remove Chrome flags after two years. (This is buried in an issue discussion somewhere.) This was a compromise. I advocated for removing them as soon as the stable version of a feature is out.

[queengooborg]

So what do you think about features that are only available in Canary releases, @jpmedley? Should we treat it similarly to flag data, or perhaps less than so and remove it immediately?

[jpmedley]

When is anyone ever going to need it?

[queengooborg]

That's the answer I was hoping to hear. :D

[ddbeck]

This issue is touching on several questions, almost all of which have been discussed elsewhere. Narrowly, I think the headline question will be resolved by sorting out a guideline for all-false data (see #10619). My inclination is to close this in favor of other issues, though I'm open to being convinced that this is a distinct question.

Some more details:

• Support statements for "preview"-only features (that is, Nightly, Canary, TP, etc.) that never make it to a numbered release and are removed will become false support statements (i.e., { "version_added": "preview" } upon removal becomes { "version_added": false }). Once all browsers remove such a feature, it becomes all-false and will have to be resolved by whatever mechanism we choose to drop all-false features in Data guideline for all false features #10619. In other words, I don't think there's anything unusual about "preview"-only removals.

  (Also, I don't think this issue is asking this but for the avoidance of doubt: I can't imagine any sensible mechanism by which we'd remove features with valid { "version_added": "preview" } support statements. 🙅 )

• Features behind flags that ship to a numbered version (i.e., statements like { "version_added": "123", flags: […] }) are covered by the not-at-all-buried irrelevant flag data guideline and the irrelevant feature data guideline. The flagged support statement can be removed two years after it's enabled by default (i.e., after two years of being a dead flag). Alternatively, the whole feature can be removed two years after the last browser to drop the feature, flagged or not.

• More aggressive disposal of dead flags (like Joe's suggestion to drop dead flags immediately) has been discussed extensively in Choose and document a policy for flagged features  #3318. This presents a bunch of content and process problems, which is probably best summarized by my comment with one proposal. I don't want to resume that discussion here, except to say: if anyone's serious about doing this, they'll have to make a detailed proposal which handles the process questions and negative impact on readers detailed in that issue. I've been saying this for years and nobody's taken me up this. Probably because it's really hard to do.

• Similarly, the aforementioned issue has looked at the proposal of dropping flags in general. This is a non-starter. There's also the suggestion of ignoring flags from specific browsers. That's a proposal with fewer problems, but so far nobody has ever actually gone to the trouble of proposing a guideline or outlining how they're going to make it happen. Probably because it's a lot of tedious work.

The only new thing I'm noticing here is that it sounds like there's interest in abbreviating the time for removal for features which have been removed from all browsers and the feature was never available by default (or maybe it was experimental: true). That sounds sorta niche, so I'd like to see more examples where this is a live concern.

[queengooborg]

I'm going to close this since we have pretty much already established the rules for this.