User Activation API Intent to Ship

[Dave Tapuska]

I've gotten very little traction on my User Activation API intent to ship. And I'm asking for opinions about what I could AND should have done better.

For example there was a lot of confusion about it in the TAG that my explainer wasn't clear enough.

I thought I included a compelling demo how the information is currently available but is destructive to the user (and requires permissions).

Including other vendors have been silent regarding my proposal.

dave.

[Daniel Bratell]

This is purely from my personal point of view: I found the use case a bit abstract despite the demo and example. Maybe there was a reason, like it being triggered by a non-public site, but it would have been easier to understand the end goal with a more concrete example that I could empathize with. Such an example could hypothetically have made me more actively push to get it through the process rather than passively waiting for some other step (cross-vendor/tag review) to be complete.

Right now we're waiting for the tag review I believe. Did you talk with Alex about it last week?

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAHgVhZXC7tazZVfFhQVwYbk4MtD7mKrCfqH93j7N-_eJ-k7wAQ%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Dave Tapuska]

That is fine if you are waiting for TAG it just isn't clear why it is stalled. Yes about two weeks ago Alex reached out to me and asked me to provide a demo. I pointed out that there was demo buried in the explainer that the TAG seemed to have missed. I pinged him a week ago and indicated I'd push on the API owners to get a status (hence this email) but haven't heard back from him.

So specifically for AMP any message received from an iframe must come with a user gesture. (https://github.com/ampproject/amphtml/blob/e32fdddfa38e043cd1df102d50e6d12911e1227e/extensions/amp-iframe/0.1/amp-iframe.js#L635) if it doesn't then once the number of inappropriate messages from the iframe are received the connection is severed. Additionally with autoplay policy changes in M69 (and also site isolation) detecting user gestures (in a non-intrusive way) is more prone for abuse.

dave.

[Philip Jägenstedt]

I would not consider this blocked on TAG review unless that is explicitly requested by someone, as it's common for a TAG review to be filed in a timely manner and not get enough feedback.

Rather, I think we are hoping for some reaction from other vendors on the spec PR. If we cannot get one, at all, then the WHATWG bar of having two implementer interest from two vendors won't be met. If that's the case, then if we'd like to ship it anyway and bet that interest does materialize later, then we'd have to maintain the spec change separately until such a time, probably as a WICG proposal.

Hopefully speaking to people at TPAC will help, but if not, then I think articulating the web developer and end user benefit a bit more and why we think it outweighs the interop risk is the way to go.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAHgVhZViRGjUz%2BXW%2B2qB4QOQJUn3REOvC52ghxbBxpGgoaPdMA%40mail.gmail.com.

[Rick Byers]

This seems like a pretty minor / low-risk feature to me with high long-standing demand from an important partner. As long as we have some reason to think the feature can generally be useful beyond just that one partner, I'd suggest it may not the best place to spend our limited capitol pushing on the other vendors. Perhaps if Dave can succeed in justifying the user value to the API owners, and paved the path to follow in terms of WPTs and a precise spec, then we should not be afraid to move forward?

On the logistics side, we'd still want to document such apis in MDN, right? Since that documentation will want a spec link, Is that an argument for preferring monkey-patching of HTML in WICG over linking to PRs? I fear this pattern of other vendors being too busy to invest in small incremental APIs (or, in other cases, not prioritizing EM use-cases) will continue to pose a challenge in the mismatch between WHATWG working mode and blink launch process requirements. We should probably get used to having some pattern for shipping small incubation features on top of WHATWG specs....

Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAARdPYfdix2X1g9FdrRYv%3DFPM5N503SjGYH7Xjnr9gbDNmVPJw%40mail.gmail.com.

[Yoav Weiss]

From my perspective, I was also waiting on clarifications regarding the use-case that this tackles.

The AMP example is a great one, but I'd love to get even more details. "AMP needs to know users interacted with an iframe before it lets them do X because otherwise Y will happen" would have been even better to spell out. Having the use-case spelled out in terms of an AMP use-case doesn't mean that the need is AMP specific.

 

On Mon, Oct 15, 2018 at 6:51 PM Rick Byers <rby...@chromium.org> wrote:

This seems like a pretty minor / low-risk feature to me with high long-standing demand from an important partner. As long as we have some reason to think the feature can generally be useful beyond just that one partner, I'd suggest it may not the best place to spend our limited capitol pushing on the other vendors. Perhaps if Dave can succeed in justifying the user value to the API owners, and paved the path to follow in terms of WPTs and a precise spec, then we should not be afraid to move forward?

On the logistics side, we'd still want to document such apis in MDN, right? Since that documentation will want a spec link, Is that an argument for preferring monkey-patching of HTML in WICG over linking to PRs? I fear this pattern of other vendors being too busy to invest in small incremental APIs (or, in other cases, not prioritizing EM use-cases) will continue to pose a challenge in the mismatch between WHATWG working mode and blink launch process requirements. We should probably get used to having some pattern for shipping small incubation features on top of WHATWG specs....

I agree this is becoming an issue. I think the ideal solution would be to create hooks that enable to extend HTML and Fetch outside of them without monkey patching them. I'm not 100% sure how that would look like, but it seems more scalable than having the processing model for *everything* eventually integrate into HTML/Fetch. 

+Domenic Denicola for thoughts on that front.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAFUtAY9UQK%3D-07LKLhmKFgphzSbZAL_ziF4%2BPt7Nf_0UreR0Xw%40mail.gmail.com.