How to interpret the new status information?

[octref]

In the old schema, status can only be experimental, nonstandard, standard or obsolete. In VS Code, we show the property's compatibility accordingly:

function expandEntryStatus(status) {
	switch (status) {
		case 'e':
			return 'experimental';
		case 'n':
			return 'nonstandard';
		case 'o':
			return 'obsolete';
		default:
			return 'standard';
	}
}

I'm wondering for the new status schema, how do I interpret it? For the 3 properties experimental, standard_track and deprecated, are there incompatibilities or are the 2x2x2=8 possibilities?

I was just looking at a commit: https://github.com/mdn/browser-compat-data/pull/526/files#diff-8a15411d4bdcecea3f3de238c0caa64eR547-R551

How can a property at the same time be experimental, on the standard track and also being deprecated?

[Elchi3]

On MDN, we try to avoid the term obsolete and use deprecated instead. See #4519 and #265

The definition of experimental is controversial and I question the usefulness of it. Maybe we should just remove it. See #1528

I wanted to forbid that deprecated and experimental appear at the same time, but there was disagreement, see #1305 for cases where people wanted this.

[octref]

@Elchi3 Thanks for your quick answer.

Seems GH doesn't jump to the right place on that link. Here's a link to the file, where I also wanted to ask how to interpret "on the standard track and being deprecated at the same time".

https://github.com/mdn/browser-compat-data/blob/master/api/VRDisplay.json#L1170-L1231

          "status": {
            "experimental": true,
            "standard_track": true,
            "deprecated": true
          }

Here is my current interpretation. Please correct me if I'm wrong:

1. standard_track: true + experimental: false => existing standard
2. standard_track: true + experimental: true => becoming a standard (waiting for all vendor implementation)
3. standard_track: true should always have deprecated: false
4. standard_track: false + experimental: true + deprecated: false => proposal
5. standard_track: false + experimental: true + deprecated: true => proposal picked up by some vendor, but ultimately dropped as suggested in Can a feature be experimental and deprecated at the same time? #1305 (comment)
6. standard_track: false + experimental: false => dropped proposal, and therefore deprecated must be true?

Currently I see 3 inexplainable combinations in 3 and 6:

• In 3, standard_track: true + deprecated: true + experimental: true/false (In RFC: Deprecated vs. Obsolete #265, you mentioned this for deprecated: "For Web standard technology, the API or feature has been removed or replaced in a recent version of the defining standard.")
• In 6, standard_track: false + deprecated: false + experimental: false

It would be great if there can be a table that defines what these combinations imply. Otherwise it's hard to interpret and also hard to contribute to the data.

[Elchi3]

3\. `standard_track: true` should always have `deprecated: false`

I'm not sure about this one. getYear is standardized but authors are discouraged from using it, hence it is marked as deprecated.

It would be great if there can be a table that defines what these combinations imply. Otherwise it's hard to interpret and also hard to contribute to the data.

I totally agree! I think this is important enough that it is more of an MDN wide issue imo than just BCD. Tagging @chrisdavidmills for opinions, too. Chris what do you think here? I know at least some of these questions were also discussed with other vendors in the MDN PAB. Any resolutions there? These status fields ultimately send out usage recommendations to our readers. How can we define them more precisely?

[chrisdavidmills]

3\. `standard_track: true` should always have `deprecated: false`

I'm not sure about this one. getYear is standardized but authors are discouraged from using it, hence it is marked as deprecated.

Yeah, I was going to comment on this one too — it is definitely possible to have something that is defined in a standard, and implemented in browsers, but which has been marked deprecated and so will be removed at some point in the future, and possibly superceded by another feature.

"For Web standard technology, the API or feature has been removed or replaced in a recent version of the defining standard."

Yeah, I'm not so sure about this either — I understand deprecation as being "marked for removal", and not necessarily yet removed or replaced. A wording update needed?

It would be great if there can be a table that defines what these combinations imply. Otherwise it's hard to interpret and also hard to contribute to the data.

I totally agree! I think this is important enough that it is more of an MDN wide issue imo than just BCD. Tagging @chrisdavidmills for opinions, too. Chris what do you think here?

Yes, I agree — understanding these different combinations can be a challenge, so it would be valuable to have a table that explains each one. This is mainly to do with compat data, so I think this table could live inside the BCD repo, rather than on MDN (but I am open to opinions here, of course).

I know at least some of these questions were also discussed with other vendors in the MDN PAB. Any resolutions there? These status fields ultimately send out usage recommendations to our readers. How can we define them more precisely?

I don't think we really really reached any resolution at the PAB on these things. Would a good approach be to create a draft of the explainer table as mentioned above, and then send it round to the PAB members for review/opinions?

[octref]

Thanks for the clarifications. I don't know if it's too late to revise the schema, but currently it would be hard for users to interpret & use a property based on this matrix. For example, in the past there was very clear distinctions:

• Experimental: not standard yet, might be implemented by browsers, API might change, use at your own risk.
• Standard: standard, might not be implemented by some browsers yet. I check browser coverage. If it's all good, I use it. If not all good or I need it for older browsers, I use a transpiler.

However the new schema put me in dilemmas. When standard_track is true, if experimental is true — does that imply the current API could still change and it's not safe to use? If deprecated is true — should I or shouldn't I use it at all? Does standard_track: true + deprecated: true indicate it'll be in the standard or not?

I'd suggest letting the real world usage inform the schema decision. Basically, what people of transpilers (such as postcss / autoprefixer) would hope to get out of BCD and what the API/proposal champions hope to signal to consumers.

[chrisdavidmills]

@octref I think we can agree on meaningful interpretations of these combinations to go forward with. So the above combinations you have queried:

When standard_track is true, if experimental is true — does that imply the current API could still change and it's not safe to use?

I would say yes. standard_track true means it is specified somewhere on the standards track. Experimental means it is subject to change, so you shouldn't really use it in production yet.

If deprecated is true — should I or shouldn't I use it at all?

Deprecated is a sign that the feature will be removed at some point in the future. This can take a long time, for example we are only just now talking about removing AppCache, and we deprecated it like 3 years ago? So to me at least, this means "don't use this in new production code, and aim to update existing production code to use something else, as it'll stop working at some point in the future". One useful data point we could consider providing is advice on what alternative to use instead.

Does standard_track: true + deprecated: true indicate it'll be in the standard or not?

Yes, it should still be in the standard in this case. When it is removed from the standard we should then set standard_track: false.

[ddbeck]

Does standard_track: true + deprecated: true indicate it'll be in the standard or not?

Yes, it should still be in the standard in this case. When it is removed from the standard we should then set standard_track: false.

Also worth mentioning here are cases where features may be explicitly deprecated by a specification. A couple of examples I've seen recently include the Obsolete but conforming features in HTML or <compat-auto> values for the CSS appearance property. It's possible such features might persist as standard_track and deprecated indefinitely.

[queengooborg]

I think that #9933 updated our documentation well to explain what each status property means and how to interpret it, so I'm going to go ahead and close this issue. If there's any further questions, don't hesitate to ask!