Tess: Alice & I met on this. Alice posted our feedback on the issue 3 hours ago. feedback on the issue 3 hours ago.

Alice: ...some more worked through code examples. .. notes in comment... didn't answer is it possible to have different instances one one app... proliferation of libraries... In the navigator issue - issue 14 - I brought it up again... 

Tess: Part of what confuses me about that is they are putting off using this from a service worker until the future, but in the wild the common "per-app" case they seem to want to address right now is the add-to-home-screen scenario, where you may reasonably expect there to be a service worker (and it may want to update the bage number when the app isn't active).

Dan: is the feedback being taken on board?

Alice: the navigator feedback yes.  I will talk to them about other feedback.  ​​​​​​​

Tess: I don't think we heard back...

Alice: I had a chat with them about the feedback. they have a PR in their repo to update the explainer. They hagd one change which was to make badge into a namespace. I went through the feedback with them. They had some convincing answers to feedback and they are working those into the explainer - it's in PR state right now. Jay says to wait a week

Tess: We got a big response late last night addressing several of the points we made; haven't yet had a chance to digest the reply enough to respond. It was also in reply to Alice's comments; would love to hear her thoughts.

Dan: Bump it a week?

Alice: suggest we bump...

Dan: agree

Alice: 1 wee

Alice: Checking if they've updated their explainer.

Alice: One of the main sticking points was the difference between badging for a page and badging for an origin. I asked them to give some examples of each. They explicitly want this to be badging for an origin, since it's about badging an installed web application.

Alice: They had a PR...

Alice: reads from something -- (1) and (2) but not (3) https://github.com/WICG/badging/blob/master/explainer.md#What-to-Badge

Alice: If you have a github issue, you'd be able to badge whether or not the PR has been approved since that state is specific to a URL. If you have comments that have come in, the per-document case.

David: ???

Alice: distinction between any tab at that URL, versus the state of that particular tab even if multiple tabs at the same URL

Alice: That doesn't rule out badging a tab, but I understand they don't intend to flesh out the tab case anytime soon.

Alice: ? about scope. Maybe something for me, Tess, and David to discuss as well.

Peter: next week?

Alice: sure

Alice: Breakout last week. This has gotten into an interestesting state. Marcos has been (reasonably) insisting on having some Tab badging. If something is a PWA it must work in a load-from-URL-in-a-tab context as well. It would be great if you didn't have to know which context you're in and badge tab with classic favicon/title munging. That's quite sensible. This kind of goes outside scope of what API authors originally intended. They've been trying to figure that out. And trying to figure out the difference between what is a "installed web app" and what's a page in a tab, and what the differences in the API surfaces in those cases. So they went in a direction of being able to set a badge on a Scope (a URL). Matt has been working on explainer to clarify a lot of these things. Matt was working on it originally, then others for bit, now Matt is back. To accomodate this in the API you can set the badge for a particular scope. This allows different tabs on the same origin to have different badges, for a start.

Alice: Tess raised the question... I brought up that Chrome may not immeditaley implement the UI side of this. Tess raised the question of progressive enhancement. No way to know, if you set the badge on a scope, whether that's worked.

Dan: Leave that up to a polyfill?

Alice: You could use the genuine badging API, and it may not set the tab badge. It may only set the PWA badge. If support for badging tabs not yet implemented.

Alice: API doesn't rule it out, but may not ship it all at once.

Dan: But API editors have listened to marcos's feedback.

Alice: yes

Dan: As someone with interest in PWA story, I tend to agree with that reasoning. Shouldn't be a depnedency on installation. Has there been discussion of dependency on manifest?

Alice: We discussed that a bit in breakout -- think it was a misunderstanding. I don't believe it does depend on a manifest.

Dan: It strikes me that mention of scoping it at a certain URL -- manifest also defines that scope.

Dan: PWA in manifest - could say, should sit in a tab, not full screen. Appears to be a little redundant to have another way of setting scope, when you already have manifests that set scope.

Alice: Badge is associated with a scope, not setting a scope.

David: also service workers have a scope

Alice: Note in the explianer -- scope may need to be in its own spec since referenced by service workers, app manifests, and badging.

Dan: What is a scope? Slightly more than an origin?

Alice: Seems to be a URL.

Alice: In the explainer: https://github.com/WICG/badging/blob/master/explainer.md#badging-for-multiple-apps-on-the-same-origin-as-in-the-case-of-multiple-github-pages-pwas

Dan: I wonder if we should add something about scope to the design principles.

Alice: I wonder.

Dan: Sounds like going in a positive direction.

Alice: Yes, I think it is. Helps that I've been able to have multiple in-person conversations with Matt and others.

Alice: To finish up the fallback thing -- Matt put the last comment on, and suggested that it needs some indication as a developer of whether Badge.set() worked, so you can do a fallback action. Not sure if that's in the explainer yet.

Dan: Does TAG need to continue to engage, or are we done?

Alice: Are we happy with set for a scope?

Tess: I think so.

Alice: So basically LGTM with a way to check that the badging API has worked.

Tess: I'm glad Matt agrees about ?? to effectively use this API.

Dan: So I think we should leave that feedback on our issue-- what Alice just said. And thank and close the issue from our side.

Alice to do that.

Alice: i spent time working with Matt on this one. Looks like they are going to split it out into document badging vs. scope badging - scope badging will be more useful for the app use case and document badging will be more useful for the tab use case.

https://github.com/WICG/badging/issues/49#issuecomment-521882946

... I was fairly convinced that this was the right thing to do - they ended up here based on Tess's comment on feature detection. Scope level would be: everything with the same URL would have the same badge status, whereas you could imagine different documents having different badge statuses. e.g. github comments. Then once you have the 2 different types of badging. You can get scope like behaviour using the document API - 2 windows open to the same gmail inbox they will both get the same info fromt he server about the nunber of unread emails...

Hadley: wouldn't gmail be scoped anyway? Issues in github - makes sense

Alice: you could have 2 tabs opened to the same github issue but ...

Alice: they have work in progress to split.

Dan: what if I am writing a simple application and I just want to set a badge and I don't care if it's a document or a scope?

Alice: the fact that there are these 2 close concepts means .. if as a developer you want both then you need to set both. if you're writing something that can be installed (a manifest) then you will need to set the scope-level

Hadley: 2 different scopes ...

Alice: it's about whether the info you're conveying via the bedge makes esnes for the scope - an origin sort of - vs the document.

Hadley: granularity.

Alice: you could have both. you could have 2 windows open to the same gmail inbox.

Alice: they are going to write it up... Otherwise they will get back to us. [pending external feedback]

[bunped to f2f

Alice: Tess, let's hang on the line to chat about this if we have time

Tess: ok

Discussion of new explainer.

Alice: two different types of badge... Two separate APIs - I believe it's necessary...

Alice: good to see feature detection right in the explainer... That seems to address the feature detection side of things.

Dan: I was concerned about the need for 2 APIs... I was concerned about the simplest use of this API - e.g. by indie app developers...

Alice: in their issue #49 I wrote some explanation.

Alice: I feel like I want to bikeshed the names...

Alice: "Client" is document, not Scope... App is Scope.

Alice: if you're badging a scope then it's also going to badge things like bookmarks.

Dan: Scope has a lot of different contexts.

Alice: I think Client should be Document... I think we need Tess on this as well. Tess was asking why it couldn't be declarative. Let's pull it into the plenary discussion.

Kenneth: ?

David: I think we had neither Tess nor Alice so wanted to bump to plenary.

Peter: now or face-to-face.

Alice: Should we wait for Dan? Not sure how good videoconferencing option at face-to-face will be? Tess and I probably most active on issue.

Alice: If we were to talk about it now... Tess and I talked a couple weeks ago. We disagreed on whether there should be 2 APIs. I'm reasonably convinced there should, Tess is not. I'm uncomfortable with 2 APIs looking so similar; Tess thinks they should be more similar and in fact the same.

Tess: That's a fair summary.

Alice: I think the fact that there are 2 APIs that look exactly the same will create confusion. navigator.setClientBadge versus navigator.setAppBadge. I'd want the APIs to look different. setAppBadge is where there's only one surface (icon/bookmark); I think setClientBadge should perhaps live on document, very different because they're different things.

Tess: I'm comfortable with you providing that naming feedback on the issue. I'm with you on the naming. Could be comfortable with navigator.?.setBadge and document.?.setBadge. Or maybe one of them isn't called badge at all?

Alice: I can talk to Matt.

Tess: Maybe Dan will have a third set of thoughts.

Alice: I'll give feedback, and we'll check in again at face-to-face

[bump to plenary for now

Alice: I was supposed to do something...

Tess: I've not yet read the updated explainer.

Alice: (makes reminder)

Bumping out 1 week

Alice: I had a chat with Matt. I've been convinced for a while (though I think Tess disagrees) that tabs API and app API are significantly different and have different use case. As such I think it would be nice if the tabs version of the API was more closely tied to the document (makes no sense on navigator). Current design is a weird compromise based on lack of agreement whether they were different use cases or not. I think we need to pick one, I would pick being different. That's the comment I need to leave

Alice: Still haven't written up a comment.

[bumped

Alice: reads her comment from 10 days ago and Matt Giuca's reply.

Tess: I don't have a strong preference between document or navigator.

Dan: Can we close?

[agreed to close

Dan: I don't feel like we can deal with this one without Alice & Tess... Let's bump to the plenary call

[ran out of time; pushed to breakout C