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.

Sign up for GitHub

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

Jump to bottom

Adding the Badging API feature #1376

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Adding the Badging API feature #1376

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
6e78b5d
Adding the Badging API feature
tropicadri Jul 11, 2024
a7cbdb3
Merge branch 'main' into badging
tropicadri Jul 16, 2024
9304ef2
Merge branch 'main' into badging
tropicadri Jul 30, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions features/badging.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
name: Badging
description: Using `navigator.setAppBadge()` and `navigator.clearAppBadge` installed web applications can set or remove (respectively) an application badge, which is usually shown alongside the application's icon on the device's home screen or application dock.
spec: https://w3c.github.io/badging/
compat_features:
- api.Navigator.clearAppBadge
- api.Navigator.setAppBadge
22 changes: 22 additions & 0 deletions features/badging.yml.dist
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
# Generated from: badging.yml
# Do not edit this file by hand. Edit the source file instead!

status:
baseline: false
support:
safari: "17"
safari_ios: "16.4"
Comment on lines +7 to +8
Copy link
Contributor

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.

Copy link
Collaborator

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:

https://github.com/mdn/browser-compat-data/blob/3b8d8ea67b2a4bd03e8b1aaac80cb54475e221e8/api/Navigator.json#L4229-L4233

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?

Copy link
Collaborator

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I filed #1690.

compat_features:
# baseline: false
# support:
# chrome_android: "81"
# safari: "17"
# safari_ios: "16.4"
- api.Navigator.clearAppBadge

# ⬇️ Same status as overall feature ⬇️
# baseline: false
# support:
# safari: "17"
# safari_ios: "16.4"
- api.Navigator.setAppBadge