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

Feature Request: Explain "Yes" in compatibility tables #11257

Open
csbrown opened this issue Jun 5, 2024 · 3 comments · May be fixed by #11530
Open

Feature Request: Explain "Yes" in compatibility tables #11257

csbrown opened this issue Jun 5, 2024 · 3 comments · May be fixed by #11530
Labels
accepting PR We invite you to open a PR to resolve this issue. browser-compat issues related to the browser compatibility data tables (BCD) effort: small This task is a small effort. idle involves: Content Requires the attention of the Content team. p3 We don't have visibility when this will be addressed.

Comments

@csbrown
Copy link

csbrown commented Jun 5, 2024

Use Case

Currently, there are many compatibility tables on the MDN network that simply say "Yes" for compatibility with a particular browser, for example here. Apparently "Yes" means "that a sub-feature is supported... with the additional meaning that it is unknown in which version support was added". However, this information is not documented on the website at all, AFAIK, and the "Yes" is quite confusing. I witnessed first hand as a team of experienced web developers misunderstood the table on the Range page by simply ignoring the "Yes" and focusing on the actual numbers underneath, which are for a sub-sub-feature.

Feature Description

Could we document the meaning of "Yes" in this context somewhere? Preferably near the "Yes"?

For example, when one clicks on a versioned entry, an additional date of release is displayed:

Screenshot 2024-06-05 at 8 09 09 AM

When one clicks on a "Yes" entry, it just says "Yes":

Screenshot 2024-06-05 at 8 10 33 AM

Instead, it could possibly say "Yes: Latest version, Earliest supporting version unknown", or some such thing.

Appendix

Apparently MDN has had a war on "Yes" but seems to have given up on the war, so they are here to stay.

@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 5, 2024
@argl argl added p3 We don't have visibility when this will be addressed. browser-compat issues related to the browser compatibility data tables (BCD) involves: Content Requires the attention of the Content team. and removed needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. labels Jun 10, 2024
@caugner
Copy link
Contributor

caugner commented Jun 14, 2024

We would be accepting a community PR that replaces

Yes
Full support

with

Yes
Full support (earliest supporting release version unknown)

in this case.

@caugner caugner added the accepting PR We invite you to open a PR to resolve this issue. label Jun 14, 2024
@caugner caugner added the effort: small This task is a small effort. label Jun 24, 2024
@github-actions github-actions bot added the idle label Jul 24, 2024
@danielhjacobs
Copy link
Contributor

danielhjacobs commented Aug 28, 2024

seems to have given up on the war

For reference, 8 files are left that are affected by this issue, and that will reduce to 0 over time:

  1. https://github.com/mdn/browser-compat-data/blob/main/webextensions/api/commands.json - Chrome data, fixed by Update Chromium data for commands Web Extensions interface browser-compat-data#24263
  2. https://github.com/mdn/browser-compat-data/blob/main/webextensions/api/cookies.json - Chrome data, fixed by Update Chromium data for cookies Web Extensions interface browser-compat-data#24268
  3. https://github.com/mdn/browser-compat-data/blob/main/webextensions/api/management.json - Chrome data, fixed by Update Chromium data for management Web Extensions interface browser-compat-data#24278
  4. https://github.com/mdn/browser-compat-data/blob/main/webextensions/api/devtools.json - Chrome data, fixed by Update Chromium data for devtools Web Extensions interface browser-compat-data#24270
  5. https://github.com/mdn/browser-compat-data/blob/main/webextensions/manifest/background.json - Chrome data, fixed by Update Chromium data for webextensions.manifest.background.type browser-compat-data#24292
  6. https://github.com/mdn/browser-compat-data/blob/main/webextensions/manifest/optional_permissions.json - Chrome data, fixed by Update Chromium data for optional_permissions Web Extensions manifest property browser-compat-data#24093
  7. https://github.com/mdn/browser-compat-data/blob/main/webextensions/api/menus.json - Chrome data, fixed by Update Chromium data for menus Web Extensions interface browser-compat-data#24277
  8. https://github.com/mdn/browser-compat-data/blob/main/webextensions/manifest/commands.json - Chrome data, fixed by Update Chromium data for commands Web Extensions manifest property browser-compat-data#24293

@github-actions github-actions bot removed the idle label Aug 28, 2024
@queengooborg
Copy link
Collaborator

Apparently MDN has had mdn/browser-compat-data#3555 but seems to have given up on the war, so they are here to stay.

It's not that the "war" on nonreal values has been abandoned, it's just that at the time, other projects had taken priority. An Open Web Docs project has been commenced to work on removing the nonreal values once again, see openwebdocs/project#206! (And we're almost done as well!)

@github-actions github-actions bot added the idle label Nov 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepting PR We invite you to open a PR to resolve this issue. browser-compat issues related to the browser compatibility data tables (BCD) effort: small This task is a small effort. idle involves: Content Requires the attention of the Content team. p3 We don't have visibility when this will be addressed.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants