Re: [w3ctag/design-reviews] User Activation Delegation through postMessages (#347)

@mustaqahmed @annevk I'm not arguing that "user activation" shouldn't be a thing. UAs obviously already use that as a signal to gate certain features. That's fine. It's also fine for specs to refer to that, just like specs refer to "private browsing mode" and how things behave differently in that state. 

Neither of those mean that the user activation state should be exposed directly via an API (just like there's no API to determine if you're in "private browsing mode"). Frankly as a web developer, I don't care, and shouldn't care, if the page is in a user activated state, what I care about is: "can I open this popup right now?" (or other gated feature). I do not want to check the user activation state and then guess whether or not that's going to impact my ability to open a popup. What about when feature X is also gated by other things, like: is the page installed to home screen? how many times has the user visited the site? how long has the page been open? what's the battery state? what's the network connection like? 

There are all things that may gate the availability of a feature today, let alone the things UAs are going to invent tomorrow. (where is the user looking right now? is the device moving at more than xx kph?)

My argument is that the information that web developers need is whether or not the individual feature they're trying to use is available or not, not the inputs that went into that decision.

I also don't have an issue with delegating those capabilities, but instead of delegating the various inputs, delegate the actual capabilities, such as the ability to open a popup, or auto-play a video with sound, etc.

-- 
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/347#issuecomment-478093346