Attach to navigator instead?

[marcoscaceres]

@annevk suggested it might be good to just attach this as an attribute on navigator. I think that makes sense to align with other APIs (and given that one can't construct new Badge() etc).

[mgiuca]

Seems fine; I'm concerned about polluting the Navigator namespace with multiple names per API (e.g. would we still have Navigator.setBadge and Navigator.clearBadge?). But if the web platform community is OK with this then I am.

[marcoscaceres]

nah, just navigator.badge.set() and navigator.badge.clear().

[marcoscaceres]

Fixie typos 🤪

[mgiuca]

Oh so you're just proposing for the Badge class to live in Navigator?

[marcoscaceres]

yeah, sorry for not being clear.

[domenic]

Hmm, I don't see the advantage of using navigator if you're just going to use a sub-object anyway...

[marcoscaceres]

Yeah, it's somewhat cargo-cultish...

navigator.geolocation
navigator.serviceWorker
navigator.clipboard
navigator.locks
navigator.storage

and so on... I don't have a strong opinion.

[annevk]

I'd use setBadge and clearBadge btw. I don't see the need for a tearoff object.

[domenic]

FWIW the Badge.x() style seems popular with developers: https://twitter.com/domenic/status/1062497647871713280

I like it because it avoids the need for a non-constructible class like ServiceWorkerContainer and a navigator.badge.constructor that always throws a TypeError. Indeed, we invented Web IDL namespaces partially to solve these problems with the current popular style. My only misgiving would be a consistency-vs.-goodness tradeoff, but my Twitter poll makes me more comfortable siding with goodness over consistency.

[marcoscaceres]

Maybe we can get away with just setBadge() if null clears it?

[domenic]

See #19; TLDR of my argument there is that I don't recommend overloading, and think separate functions would be much better.

[fallaciousreasoning]

Just to confirm, the consensus here is on Badge.set and Badge.clear?

[raymeskhoury]

Seems like it. Closing.

[fallaciousreasoning]

Reopening this, as it came up in the TAG review. In w3ctag/design-reviews#387 (comment) @alice points out that having the badge on navigator makes it more obvious that the badge is for all instances of a site (while window.Badge looks per instance).

If we do decide to go this route, I'm partial to the navigator.badge.<x> approach :)

[domenic]

I don't quite get the reasoning why Badge (aka window.Badge) feels different from navigator.Badge (aka window.navigator.Badge) in this regard.

[marcoscaceres]

It could just be that using static methods on global objects feels a bit weird. There very few interfaces that provide static methods... while the foo.bar.whatever() pattern "feels more webby"? There is also a nice discoverability aspect to it in dev tools/dev console... like, "ooh, what does navigator.badge let me do?"... more conceptually scoped than something hanging off window? Dunno... just random guesses :)

[domenic]

I think the discoverability would actually be harmed, as you'd have to first know it exists on navigator. Although I'm not sure how much that should guide API design.

You're right that this should be a namespace (like Math, Reflect, console, CSS, etc.) rather than an interface with only static methods. See https://w3ctag.github.io/design-principles/#constructors and particularly https://w3ctag.github.io/design-principles/#example-09c8f087.

[marcoscaceres]

Yeah, I tend to agree that a Badge namespace might be the right thing here for the reasons @domenic points out. @alice, wdty? Does that sound ok?

[alice]

I'd like to better understand the answer to this related question from our review first:

we weren't clear on when the distinction between per-app and per-instance would apply (isn't an installed PWA just a single instance of an app?).

[marcoscaceres]

Somewhat related #12 and #5 ... the distinction is not something we've managed to nail down. Like, we broadly understand what it means to "install" a web app and isolate it from the browser... but then we have things like browser tabs/single-page web apps, that could also make use of this API: imagine two instances of gmail running for two different accounts, each using this API in pinned browser tabs. So I honestly don't know if we will be able to answer that particular question for a while.

[fallaciousreasoning]

A per app badge is displayed in an operating system specific location (e.g. the dock, the start menu, the home screen, the taskbar). There can only be one of these badges for an "app". What can be badged is constrained by the operating system.

A per instance badge is tied to a specific instance of a site (and so would be displayed in an instance specific location, such as the tab or window favicon). There can be as many different badges as there are instances (tabs or windows) of a site. What can be badged is constrained by the user agent.

As @marcoscaceres says, we're still grappling with this.

[alice]

For an installed app, is it possible to have more than one instance of it running?

For gmail (or slack), this is a situation I have quite often... different slack workspaces in different tabs, each with their own favicon/title status, similarly with different gmail accounts (or even the same one), similarly with calendar, etc.

[fallaciousreasoning]

For slack in particular, I believe that each workspace would have its own app (slack uses <workspace>.slack.com for different workspaces, while WebApplication scope cannot span origins). There could be multiple instances of each app open but each one would get a separate dock icon (which could be badged separately).

Gmail is more interesting, assuming you can swap accounts inside the PWA (say, having your work and personal accounts open in separate windows). There is only one place to display an application badge (the dock icon, taskbar icon or homescreen icon, depending on the OS), so the separate accounts would have to share the badge, perhaps displaying the sum of unread emails over all accounts. An alternative solution would be to create separate PWAs for each account (in Gmail, this could be done by setting the scope to mail.google.com/u/<n>/).

---

I feel like this is a good argument for keeping per-app and per-instance badges separate. The OS specific context could display an aggregate across accounts while the specific instances could display account-specific information (perhaps in their title bar icons).

[marcoscaceres]

Refocusing the discussion just on the naming of things, @alice are you ok with us going with Badge. instead of navigator.badge? Proposed change is PR #38.