Publish FWPD?

[marcoscaceres]

Be great to publish this spec as FPWD! @mgiuca @fallaciousreasoning, there are a couple of ReSpec issues by the looks of it, but otherwise it should be good to go. WDTY?

[mgiuca]

Firstly, both @fallaciousreasoning and I have been mostly absent from Badging related things. Within Google, that's how handled by @cmumford (who wasn't a member of this project... I just invited).

I think this could go to a FPWD but we should address the red issue boxes in the spec first.

The big thing for me is that per the rules discussed recently around other APIs, we aren't looking to standardize things that only have one implementation. Well this API, as far as I know, only has half an implementation (the App side, in Chromium). Nobody implements the Client side, unless Firefox has done that since I last checked.

Even if Firefox does implement the Client side, that would mean there's only one implementation of each piece of the API, so the whole thing would be at risk. Given that, does it make sense to leave this repo as-is until there are more implementations? (Note: I'm personally happy to proceed, but I don't want to do that work if we just end up being blocked at a later stage due to lack of implementations.)

[marcoscaceres]

Given there is now have an implementation in WebKit, this spec now meets the criteria of "at least two independent implementations" for publication as FPWD.

[fallaciousreasoning]

Awesome! Pretty cool to see this moving forward!

[marcoscaceres]

@fallaciousreasoning, I was unsure if you were still around and working on browser stuff. Will you still want to edit this spec? (we would need Brave to join the Working Group)... and totally ok if not. Just wanted to check before we publish.

[marcoscaceres]

Nobody implements the Client side, unless Firefox has done that since I last checked.

No support from Firefox, AFAICT.

I think it might be fine to just drop the setClientBadge() API for now.

Let's start with just the setAppBadge(). We can always bring be setClientBadge() later.

[fallaciousreasoning]

I think realistically, probably not unfortunately. I'm mostly just following this in my own time. Thanks for all your work moving this forward @marcoscaceres 😄

[mgiuca]

Is it supported in WebKit?

From the commit description:

Engine support does not mean browser support.

The standard explicitly calls out that if the User Agent does not intend to do anything with the updated
badge count then the API should not be exposed to JavaScript.
This allows for the best practice of feature detection, so web page JavaScript can put its badge count
data somewhere else that it knows will be used.

As such, WebKit support remains disabled at runtime, and only clients interested in actually using the
badge count will enable it.

This patch implements the feature by exposing a BadgeClient on Page.

I don't know what a BadgeClient is (it isn't a concept in the spec, maybe it's something to do with the browser <-> WebKit interface). If it's implemented in WebKit but not enabled in any browsers, maybe we should hold off on this until it's exposed in Safari or another major WebKit client.

I am no longer working on this API at Google. I will look at getting a contact on the relevant team.

[marcoscaceres]

I don't know what a BadgeClient is... browser <-> WebKit interface

Basically, yes.

If it's implemented in WebKit but not enabled in any browsers, maybe we should hold off on this until it's exposed in Safari or another major WebKit client.

The idea of publishing is to gain implementation experience and receive wide review before it is put out in the wild. Otherwise, implementers risk ending up ending up with web compat issues. Being in WebKit means we can run WPTest against the implementation (and otherwise poke at it) until we are confident that it's worth enabling in a product (such as Safari)... but not before.

For what it's worth, it's already exposed in minibrowser (so technically, "it works" even if it doesn't set any actual badge).

[marcoscaceres]

Closing this issue and will start a proper CFC to publish with the working group.