`standard_track` is redundant when there is `spec_url`

[saschanaz]

Having a spec URL should automatically say it's on a standard track. But since not all data have spec_url, maybe at least make sure standard_track is consistent with the value of spec_url and ultimately remove the field?

[foolip]

See https://github.com/mdn/browser-compat-data/issues/11216 for creating a guideline around spec_url generally.

[gsnedders]

How far away are we from having spec_url everywhere? I'd rather put effort into getting that done rather than dealing with standard_track.

[saschanaz]

Modifying required field in compat_statement in schemas/compat-data.schema.json suggests there are tons of data that lacks spec_url.

[gsnedders]

Filed #12709 to add what webref knows about, but there's still a lot of omitted spec_url, especially with things like worker_support and event handlers and optional parameters/dictionary members.

[ddbeck]

It seems likely that spec_url implies standard_track is true. We probably ought to enforce that, but I can't be sure of it without having agreed guidelines for spec_url. Which is to say, #11216 blocks a serious discussion on this.

(Provided we can create a fixed requirement for standard_track → true, then we can move toward removing standard_track outright, if we can show that the meaning of standard_track: false is "doesn't have a valid spec_url.")

[gsnedders]

It seems likely that spec_url implies standard_track is true. We probably ought to enforce that, but I can't be sure of it without having agreed guidelines for spec_url. Which is to say, #11216 blocks a serious discussion on this.

(Provided we can create a fixed requirement for standard_track → true, then we can move toward removing standard_track outright, if we can show that the meaning of standard_track: false is "doesn't have a valid spec_url.")

#6103 also touches on a bunch of this discussion, specifically about whether WICG documents (which aren't on the W3C Recommendation track) are "standards track".

[foolip]

there's still a lot of omitted spec_url, especially with things like worker_support and event handlers and optional parameters/dictionary members.

I think this will remain the case, and isn't something we need to fix. If we add a lint, it could be:

• features with spec_url have to have standards_track set to true
• where spec_url is missing from a feature and all ancestor features, standards_track has to be false
• no constraints for features missing spec_url where some ancestor does have it

[martinthomson]

Why would a specification imply that something is a standard (or on track to be one)? Any crank on the Internet can write a specification. Many do. Some of them end up on standards tracks of various sorts.

Mozilla has a more advanced set of definitions that might be a better substitute than testing for the presence of a specification. Of course, that might mean some judgment is involved, which means documenting some guidelines.

FWIW, WICG documents - or any CG document - should not be marked as standards track. Yes, they might eventually become standards (many have done so), but many others never go anywhere.

(Chris Wilson suggested that maybe you flag incubations; I would say that standards_track being false with a specification is exactly what an incubation should look like.)

[sideshowbarker]

As I’ve said at https://github.com/mdn/browser-compat-data/issues/6103#issuecomment-625024050 and elsewhere, we are going to be much better off if we just remove standard_track altogether. What’s “standard” is subjective, and among the various stakeholders involved in wider discussions about what should be considered a standard and what shouldn’t be, we’ve never — in years of having discussions about it — arrived at any agreement.

More details and examples about why trying to identify what’s “standard” and what’s not is problematic:

• https://github.com/mdn/browser-compat-data/issues/6103#issuecomment-625003114
• https://github.com/mdn/browser-compat-data/issues/6103#issuecomment-624996231

In contrast, whether or not something has a spec is a fact that we can objectively measure. Even if the only spec for some some feature were written by a crank on the Internet, that’s still a spec. And for BCD and MDN purposes, it’s not our goal to be making judgement calls about the quality or provenance of particular specs.

For MDN purposes, we minimally need a spec in order to try to document a feature. Otherwise, if we don’t have a spec for a feature, then the best we can do is to try to document which browser engines the feature works, and how it works in those engines.

And in some cases in MDN and BCD, we have features that developers want to understand but that we don’t have a spec for. So part of the value of the spec_url data on those cases is that, if we don’t have a spec_url value, then we can clearly signal to developers: This feature has no specification — and so the MDN documentation may not be based on anything more than somebody having tried the feature in browsers and documented what they found.

As far as whether something is considered a “standard” or not, in my experience, developers coming to MDN don’t care whether somebody else has decided a feature is standard or not; instead what they care about is, understanding the feature and getting some help and guidance with trying to use it in their code — even in cases where that feature may only be implemented in only one browser engine (and even in cases where it seems pretty clear that feature is never likely to end up being implemented in any other browser engines).