We could add spec_url or spec_urls alongside with the mdn_url that we already have in this data and then remove status.standard_track. If a feature then has no spec_url(s) property, it can be marked as non-standard.

We will need to figure out what the spec_url(s) of certain sub-sub-features would be, though.
For example what would be the spec_url(s) of javascript.builtins.Date.toLocaleDateString.iana_time_zone_name which is standardized.

Currently, in the wiki, the full specification URLs are not put on each reference page, because URLs of specs change sometimes, so we've put them in specdata.json. Now I think it is fine to put the full URL into a spec_url(s) property in this repo, because if a spec's location changes, we can grep and mass change this in git more easily than in the wiki, so this isn't a problem anymore. And I think I would prefer that over a property called specification: "ECMAScript" because with a URL we would also provide deep links to spec documents which was requested in #1336. (A specdata dataset could probably then provide the specification statuses plus spec names/identifiers and we map them to the domains that occur in the spec_url(s) property here if needed.)

Then there is the question whether it would be spec_url or spec_urls. MDN includes competing and historical specs on reference pages. This is actually quite confusing to web developers and maybe only appreciated by standards people, although I hear them cringe whenever we have old specs on the pages. For competing specs it is mostly W3C vs WHATWG I think. The most relevant spec, if we would do just a single spec_url, is probably the spec that browsers implement, but unsure if that is always the same spec. Any advise?

FWIW I think spec_urls: [...] would be best; ideally, articles would also pull SpecData.json so that things like "Working Draft", "Living standard", "Obsolete", etc. can still be surfaced. IMHO the issue of confusing developers when when multiple things are linked can be solved at the level of the UI. (E.g., Only display spec_urls[0] and make sure it's the latest/most active, or use faded/greyed-out colouring for spec_urls[1...], etc.).

We've updated the schema to include "spec_url" and have added spec links for ECMAScript for a start in #2983. Many thanks to Michael Smith aka sideshowbarker for this work.

A linkage between |MDN docs <-> compat data <-> specifications| is now possible. We will add spec_url to more features in this repo as time permits. PRs welcome.

ideally, articles would also pull SpecData.json so that things like "Working Draft", "Living standard", "Obsolete", etc. can still be surfaced.

Currently we think that exposing spec statuses in MDN documentation is not helpful and we should probably not do this at all anymore. Compare mdn/kumascript#1019

I will leave this issue open to investigate if we could remove the "standards-track" status property in favor of spec_url, or if (long-term) we end up needing both.

#15889 introduces a linter update that will make standard_track's value based on the presence of a spec_url. This is the first step towards the potential removal of this status property.

Just a thought. If you remove standard_track consumers of the data will need to implement their own logic to render it. That's not to mention that you could be breaking existing logic by removing it.

This is a valid concern, @jpmedley -- I think the idea is that consumers should be using the presence of spec_url to determine if a feature is standard, which is what we're working to enforce now. This would definitely need to be in a major semver bump, since it is removing something from the schema.

Is there some way to investigate whether folks generally know how to determine that from the spec? I misunderstood the ins and outs of that for years despite it being a core requirement of my job. I'm worried that different consumers will return different results and the capacity for confusion will be high.

In the release notes for a release that would remove the status property, we would make sure to point consumers in the right direction with a note along the following lines:

The status.standard_track property has been removed from BCD as it is now redundant. Consumers should now determine if a feature is standard based upon the presence of a spec_url property on the feature.

The status.standard_track property has been removed from BCD as it is now redundant. Consumers should now determine if a feature is standard based upon the presence of a spec_url property on the feature.

Echoing @martinthomson from #12685 (comment), I believe this change would cause an important distinction to be lost. While third party tooling could implement their own rules (i.e. to filter out features with spec_urls that aren't on a standards track), the standard_track field is used on MDN and other consumers to badge and inform developers about features that are likely to have poor cross browser support or may be unstable.

Is the intent that MDN would change the logic to badge compat warnings based on a given spec_url (i.e. if it's not part of a standards body) rather than the standard_track field?

Is the intent that MDN would change the logic to badge compat warnings based on a given spec_url (i.e. if it's not part of a standards body) rather than the standard_track field?

In years of discussion about this, we’ve yet to reach agreement about what the intent is.

But what seems to me would be most helpful to developers is if we were to just do what’s described at the end of #6103 (comment):

could be more helpful to readers is a W3C, WHATWG, WICG, ECMA/TC39, IETF, or Khronos label/logo — shown in a place similar to where Can I Use shows their status indicator now

…that is, label the feature with a logo of the organization/group/project that produced the spec, and just leave it up to developers to make their own judgements based on that.

badge and inform developers about features that are likely to have poor cross browser support or may be unstable.

That’s what we have the Browser Compatibility tables and BCD data for. Developers looking at the Browser Compatibility tables can tell right away what the level of cross-browser support is for a particular feature. We don’t set the standard_track field based on the level of cross-browser support; we have many features which have standard_track set to true but that are actually implemented in only one browser engine (and in some cases, unlikely to ever be implemented in any other browser engines) — and we even have some features with standard_track set to true that haven’t shipped in any browser engine.

…that is, label the feature with a logo of the organization/group/project that produced the spec, and just leave it up to developers to make their own judgements based on that.

Badging based on the standards body (or lack thereof) sounds reasonable. In that same spirit, perhaps annotating "is currently standardized" would require less interpretation than "is on a standards track" - and be valuable information to provide developers in the sense that a feature is broadly accepted and stable.

We don’t set the standard_track field based on the level of cross-browser support; we have many features which have standard_track set to true but that are actually implemented in only one browser engine (and in some cases, unlikely to ever be implemented in any other browser engines) — and we even have some features with standard_track set to true that haven’t shipped in any browser engine.

I was referring to the current caption text and title text when hovering the badge in the table. Maybe that text should be updated to better capture the meaning of this state.

• Current caption - "Non-standard. Check cross-browser support before using."
• Current title text - "Non-standard. Expect poor cross-browser support."