Re: [w3ctag/design-reviews] Badging API (#387)

> Hi @fallaciousreasoning @raymeskhoury, I have a question about progressive enhancement & feature detection.
> 
> Suppose I'm a Twitter engineer. Twitter currently munges `document.title` to badge an unread count. I'd like to adopt `Badge.set()` when it's available, and I'd prefer to only fall back to my legacy `document.title` munging when `Badge.set()` won't work for me. How would such an author know when to fall back to the legacy code path?
> 
> My read of the proposal is that this isn't currently possible. That is, feature-detecting the presence of `window.Badge` or the `Badge.set()` method doesn't tell me, the website author, if calling `Badge.set()` will result in some kind of user-visible UI change.

This is a pretty important point. We probably need not only feature detection but some way to know whether the badge will be applied to the current tab or not (for example, Chrome might only badge the app icon but not apply it to the tab, so the feature would be present but not show anything in the tab strip.

Web-spec-theoretically we shouldn't expose the details of the UI to the developer (like we could say "it's none of their business whether it shows in the tab strip or not; you just give us the data and the UA will display it as they see fit"). But practically, because there are already ways to do this, the developer needs to know whether the Badge API will be seen in the tab, so they can turn off the fallback mechanisms. They're not going to want to use the Badge API if there's a chance of showing a duplicate badge with the title or favicon.

So we could do `Badge.canSet()` but I think we need a more advanced "will this be shown alongside the favicon and/or title?" feature detector.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/387#issuecomment-519764397