Broken link to browser compatibility section in API landing pages

[dipikabh]

MDN URL

https://developer.mozilla.org/en-US/docs/Web/API/WebUSB_API

What specific section or headline is this issue about?

Link in the page banners to browser compat section is broken

What information was incorrect, unhelpful, or incomplete?

Some API landing pages with {{SeeCompatTable}} or {{securecontext_header}} macro, which generate the following banner text, include a link to the "Browser comparability" section, but the page does not have a browser-compat key in the front matter. So the link to the browser compat section is broken:

Experimental: This is an experimental technology
Check the Browser compatibility table carefully before using this in production.

and

Secure context: This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

What did you expect to see?

Working link or no link

Do you have any supporting links, references, or citations?

At the moment, the issue seems to exist in only two landing pages (broken link to BCD section from the banner):

• https://developer.mozilla.org/en-US/docs/Web/API/WebUSB_API
• https://developer.mozilla.org/en-US/docs/Web/API/WebOTP_API

The following page does not have the browser-compat key but the "Browser compatibility" section is hand-written:

• https://developer.mozilla.org/en-US/docs/Web/API/Reporting_API

Do you have anything more you want to share?

This issue has been brought up before in a discussion (https://github.com/orgs/mdn/discussions/564#discussioncomment-1554227) and a somewhat related issue mdn/content#17550.

MDN metadata

Page report details

• Folder: en-us/web/api/webusb_api
• MDN URL: https://developer.mozilla.org/en-US/docs/Web/API/WebUSB_API
• GitHub URL: https://github.com/mdn/content/blob/main/files/en-us/web/api/webusb_api/index.md
• Last commit: mdn/content@4458494
• Document last modified: 2023-12-10T06:28:37.000Z

[hamishwillee]

Shouldn't this be a yari bug?

We know that we want to be able to mark API pages as secure context, experimental, deprecated, but that generally we to not want to include browser compatibility information in them.

The discussion essentially says we need some way to squelch the link. I like jpmedley suggestion of doing this based on the content, though I would do this based on the existence of a heading Browser compatibility. Harder for yari to read than metadata, but that's what the link is actually looking for.

I might add a note to the discussion.

[OnkarRuikar]

This can be handled in yari by checking if the page doesn't have browser-compat front-matter key then use shorter versions(without compat links) of these messages.