MDN URL per feature

[foolip]

In order to support https://github.com/GoogleChrome/webstatus.dev/issues/295 we'd need a MDN URL per feature and publish it as mdn_url or similar.

We can get MDN URLs from BCD, but for most features we'll have more than one. If so we need to pick one of them, or sometimes another page that's about the feature as a a whole.

cc @estelle

[captainbrosset]

I toyed a little bit with this on this dashboard I made: https://captainbrosset.github.io/web-features-explorer/recent/ Click on a feature's Learn More link to see MDN link(s). The code is not pretty, and it makes no attempt to have just one URL. In fact I don't think we will be able to always have just one. The code just kind of simplifies the links, and groups them by technical areas. See https://github.com/captainbrosset/web-features-explorer/blob/main/.eleventy.js

I don't think that's what you wanted here, but I thought I'd mention it anyway. This could be a solution that doesn't require maintenance.

[foolip]

We could quite easily generate mdn_url which could be one or more URLs, and then override it to be a single URL when that makes more sense.

[captainbrosset]

I guess we could also map markdown articles in the mdn/content repo to web-feature IDs, like we do in BCD.

[ddbeck]

I think this has gotten a lot more tractable now that https://github.com/mdn/browser-compat-data/pull/23431 (and attendant fixes) has landed. Starting with the next BCD release, we can expect BCD's mdn_urls to not 404.

So I'd probably suggest a strategy like this:

• Let web-features have an docs_url or mdn_url field that's a string or an array of strings.
• In the dist file, roll up all the compat features' MDN URLs as an array, sorted by the number of / in the URL. This should get you the most-general pages first (e.g., interfaces before properties)—one of the first few URLs will be at an appropriate level of generality.
• If you don't like the result (e.g., you'd rather have the overview page that doesn't have a compat table, such as grid layout), override it in the authored YAML. The auto-generated list will probably give you some good candidates to pick from, in most cases.

Alternatively, we could use the MDN content inventory directly instead (e.g., finding pages that cite the feature's compat keys in frontmatter). This is more likely to find overview pages (e.g., Clipboard API — I don't think any BCD object links to pages like this), but won't be as strict (any arbitrary page can have a compat frontmatter key).