Browser-compat-data: Investigate if we still need status.standards_track if spec_urls are populated throughout the repo

[dontcallmedom]

Rather than maintaining the "standards-track" status for each feature tracked in BCD, it would probably be best if a given feature could be attached to a given spec (or set of specs) - that way, the standards-track status of the page could be determined from the separately maintained status of specs.

If so, we should be able to do a one-time scraping of spec infos from existing MDN pages to automatically bind features to the specs that define them to update BCD en masse.

[Elchi3]

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 https://github.com/mdn/browser-compat-data/issues/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?

[mdittmer]

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.).

[Elchi3]

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 https://github.com/mdn/kumascript/issues/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.

[jpmedley]

I didn't comment because I didn't think you guys would actually do this. The first line of defense against loss of data integrity is to deduplicate. Yet this duplicates information that's in SpecData.json. Am I missing something?