...thought WebKit was on-board with explicit APIs that can be controlled vs. silently bad behavior that's hard to understand and mediate (1px video hack, e.g.)?
-
-
Does Blink intends to give *all* websites this ability, and not just privileged “installed” ones? (E.g. “save to home screen”) Your replies make it sound like it, but maybe I’m wrong? If so, that might be a core disagreement. (Not saying there’s not others)
1 reply 0 retweets 2 likes -
There's some nuance here (and Twitter is a bad place for that!), but will try to outline the space we're working through. With all our extended capability work, we try to ensure APIs request the capability via a Promise-returning method:https://groups.google.com/a/chromium.org/forum/#!topic/Blink-dev/KMNZmMF1_H4 …
1 reply 0 retweets 0 likes -
Replying to @slightlylate @bradeeoh and
...and we work to make sure folks are integrating through the Permissions API for introspection: https://w3c.github.io/wake-lock/#permissions-and-user-prompts …
1 reply 0 retweets 0 likes -
Replying to @slightlylate @bradeeoh and
Together, those choices mean that UAs are allowed to implement whatever UI and grant/deny behavior they want. That's in addition to the normative restrictions we *tend* to put on powerful APIs that aren't as controversial (secure origin, top-level document, etc.)
1 reply 0 retweets 1 like -
Replying to @slightlylate @bradeeoh and
So what's Blink gonna do? It might change! There's an allergy by some on the team to gate on install, so instead we use install to signal that an app is "high engagement", then gate (some) API access for *that* (a fully local calculation): chrome://site-engagement/
1 reply 0 retweets 0 likes -
Replying to @slightlylate @bradeeoh and
My expectation is that we'll start with a prompt for top-level, TLS-served documents that aren't installed/high-site-engagement. Which is to say "yes", we'll likely enable this interface for all sites. But it's a dynamic line, and we want user and developer feedback to adjust.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @bradeeoh and
One (likely) adjustment is to make the capability more persistent for high-engagement (installed) sites. E.g., you might be re-prompted regularly in a tab whereas that might not make sense once installed. ...but there's a ton of stuff that's moving in this space.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @bradeeoh and
For instance, we're working on new ways to understand low-accept/high-prompt rate annoyances -- we see this a lost for Notifications -- and the infra for that should be generic-ish.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @bradeeoh and
The other side of this is that the APIs we expose for requesting permissions are a place where the platform is under-developed. We've argued for years that the Permissions API needs `request()` and `drop()` methods to make it easier to give more scoped/limited grants.
1 reply 0 retweets 0 likes
There's a loooong set of conversations we can have about prompts & user activation & usage indicators & persistenc & time/location limits & site reputation/engagement. The space is unsettled; I'm eager to see different UAs take different approaches.
-
-
Replying to @slightlylate @bradeeoh and
Anyhow, what I'm trying to get at is that even if we disagree about the specifics of what each of our products would do in terms of gating this today, that's great! We're totally down with that. If Safari wants to restrict this to installed PWAs, seems good!
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.