-
Notifications
You must be signed in to change notification settings - Fork 64
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
Adding the Badging API feature #1376
base: main
Are you sure you want to change the base?
Conversation
safari: "17" | ||
safari_ios: "16.4" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is unfortunate and due to the fact that BCD shows Chromium as partially implemented only.
Badging does work on Chrome and Edge, for installed apps on Windows and macOS, and is documented in multiple places. So, having web-features saying otherwise is a bit of a shame.
@foolip do you have any suggestions? How have we delt with this in the past? Should we allow some wiggle room for editorial overrides for this type of things where, yes, it's not all green, but making it red gives the wrong idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the problem is here in BCD:
And using partial_implementation
there is in line with BCD guidelines:
https://github.com/mdn/browser-compat-data/blob/main/docs/data-guidelines/index.md#operating-system-limitations-imply-partial_implementation
This is very similar to Web Bluetooth, which is also not supported on Linux. I used a status override for that in web-features:
web-features/features/web-bluetooth.yml
Lines 19 to 21 in 9189c4c
chrome: "70" # macOS and Windows, not Linux | |
chrome_android: "56" | |
edge: "79" # macOS and Windows, not Linux |
I think we can do that here too.
Unfortunately, the dist files still have the data derived from BCD, blessed as correct:
web-features/features/web-bluetooth.yml.dist
Lines 5 to 7 in 9189c4c
# baseline: false | |
# support: | |
# chrome_android: "56" |
@ddbeck any ideas for how we can solve this last problem?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, so there's some distinctions to make here:
-
The comments don't follow the override. Would it be helpful if they did? Or at least made it clear that the overall status wasn't derived from what's shown in the comments?
-
Do we want to override the per-key statuses, to the value of the parent feature override? Or do we want to override the BCD key statuses, then use that to calculate the full feature status?
-
If we do want to be able to override per-key statuses, do want want that to happen on a per-feature basis (e.g., it's part of the feature authoring and the scope is limited to that feature)? Or on a per-key basis (e.g., we override BCD once and for all, even once we solve the keys in multiple features problem)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I filed #1690.
No description provided.