Allow for providing spec URLs when there is no BCD table

[queengooborg]

I've thought that the use of placing the spec URLs within BCD and using it to render the spec tables has been a wonderful idea, as it helps consolidate the data in one place. However, there are some features that are documented on MDN web docs that do not (and should not) have their own compatibility tables separate from another feature, such as in the case of dictionaries. In these cases, we aren't able to take advantage of the Specifications macro and must manually create one.

We ran into this issue with mdn/content#8846 recently. Currently, in BCD, we're working to remove all non-interface data from the API folder, which includes enums, typedefs, and dictionaries. Most of the removals have been pretty trivial, where we just need to delete the file and content pages and fold their data into other features. In some cases, like the PR I linked, it's more reasonable to keep the content pages and only remove the compatibility tables.

@wbamberg wrote a comment on the PR suggesting a new key we can add as a fallback for the spec macro:

About spec tables - I think it's a bit problematic that spec URLs are tied into BCD, for reasons like this. I think perhaps we should allow a spec-urls front matter key, that the {{Specifications}} macro can consult in case the browser-compat key is missing. That way the table-rendering itself is always consistent.

[wbamberg]

@queengooborg , thanks for filing this!

Another area where this is a problem is API overview pages like https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API. BCD doesn't represent APIs, so this also has to be a hardcoded table. This is especially weird because APIs usually map directly onto specs, yet they are one of the few places we don't represent the spec as metadata.

[sideshowbarker]

@wbamberg wrote a comment on the PR suggesting a new key we can add as a fallback for the spec macro:

About spec tables - I think it's a bit problematic that spec URLs are tied into BCD, for reasons like this. I think perhaps we should allow a spec-urls front matter key, that the {{Specifications}} macro can consult in case the browser-compat key is missing. That way the table-rendering itself is always consistent.

While I think that would work great, I also think it might be better to have the spec URLs data for all the APIs in one place.

So I propose we consider putting the spec URLs in https://github.com/mdn/content/blob/main/files/jsondata/GroupData.json, and having the MDN build pull the spec URLs from there.

[sideshowbarker]

So I propose we consider putting the spec URLs in https://github.com/mdn/content/blob/main/files/jsondata/GroupData.json, and having the MDN build pull the spec URLs from there.

hmm incidentally, I notice/remember that the overview keys in GroupData.json are article titles rather than slugs; for example:

    "Background Fetch API": {
      "overview": ["Background Fetch API"],
      "interfaces": [

If we put the spec URLs in GroupData.json I am imagining that will make it become useful for some non-MDN consumers — certainly I can say it culd for some new work I am involved in at the W3C on coming up with ways to show better, more clear browser-support metadata at the top of every W3C spec.

But unless GroupData.json has the slug rather than the article title, that means my consuming code would need to do an additional lookup for the slug, based on the title which that overview now gives. And I think MDN doesn’t even expose any way that arbitrary third-party consumer code could do that.

Given that, I’d like to propose we change all the current overview title values to being slugs instead.

[schalkneethling]

@ddbeck and @Rumyra I reckon this warrants a discussion in our content engineering meetings.