Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken link to browser compatability section in API landing pages #11290

Open
dipikabh opened this issue May 16, 2024 · 2 comments · May be fixed by #11291
Open

Broken link to browser compatability section in API landing pages #11290

dipikabh opened this issue May 16, 2024 · 2 comments · May be fixed by #11291
Assignees
Labels
effort: medium This task is a medium effort. has PR Issues that already have a PR idle macros tracking issues related to kumascript macros p2 We want to address this but may have other higher priority items.

Comments

@dipikabh
Copy link
Contributor

dipikabh commented May 16, 2024

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

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

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
@github-actions github-actions bot added the needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. label May 16, 2024
@hamishwillee
Copy link
Contributor

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.

@caugner caugner changed the title Broken link to brower compatability section in API landing pages Broken link to browser compatability section in API landing pages May 17, 2024
@Josh-Cena Josh-Cena removed the needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. label Jun 6, 2024
@OnkarRuikar
Copy link
Contributor

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.

@wbamberg wbamberg transferred this issue from mdn/content Jun 11, 2024
@github-actions github-actions bot added the needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. label Jun 11, 2024
@caugner caugner added p2 We want to address this but may have other higher priority items. macros tracking issues related to kumascript macros has PR Issues that already have a PR and removed needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. labels Jun 11, 2024
@caugner caugner self-assigned this Jun 12, 2024
@caugner caugner added the effort: medium This task is a medium effort. label Jun 24, 2024
@github-actions github-actions bot added the idle label Jul 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort: medium This task is a medium effort. has PR Issues that already have a PR idle macros tracking issues related to kumascript macros p2 We want to address this but may have other higher priority items.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants