Tess: There are a lot of strong opinions. Last time there was confusion on what were being asked to review. Consensus first would be great. I'll talk to them before next wee

Hadley: I looked at this - i'm suspicious of anything that surfaces info about the user's preferences. It's an API to expose whether video will autoplay in the user's browser. One thing I would like to see is what it does to the fingerpinting surface. Could be a copy-paste from intersection observer and the like....

Tess: It's a little hard to follow from the design review issue filed. There is a fundamental disagreement on the shape of the API. There was a f2f in NY in March where we discussed this. The gekko and webkit media folk would strongly prefer it to be a syncronous propery lookup. The blink engineers want it to be promise based.

...There's reasonable arguments to be had here. Autoplay is a weird area - different enginess have different policies, applied differently. Architecture in Blink involves XPC. If they have to prefetch this at page load time then it hurts page performance. Both gekko and webkit policies work differently from that. no consensus in the room whether it should be sync or async.

...Raising this to the TAG was maybe intended to both be a simple design review and partially invoking TAG as an esclation path. I think there are 2 relevant html design principles. One is priority of constituencies - improving experience for users comes first before browser enginers. Second is avoiding needless complexity. Since two independent implementations prefer the simpler API, this feels needlessly complex. We should prefer the simpler API.

David: are there other APIs that synchronously need this information? Like play APIs where you can detect if it works?

Tess: yes.

Sangwhan: you get a promise.

Tess: this is trying to add convenience on what you can already do.

David: if some browsers have this per element this is n issue if the API is per document.

Tess: the API is both. Programatically detect behaviour under different implementations. You do need document and element level. One architecture issue is that you shouldn't have this divergence to begin with.

Sangwhan: i did look into this - i couldn't get to the bottom of how autoplay is actually implemented. i could not figure it out.

Hadley: yeah i went digging into that too.

Sangwhan: i looked at both sides of the argument - property vs. async - it feels more ergonomic to have it as a property - as someone who might use it as a web application.

Peter: one argument in favour of a promise base... []... but one argument is this can change so you might want an event.

Tess: one option considered in march is an object could receive an event. It ended up being the most complicated. So it's worth saying that the underlying implementation issue (XPC in Chrome, and that loading it is expensive): in webkit I think we do XPC at pageload time for a variety of reasons already. So i don't think "we do xpc here" justifies the complexity.

Peter: i agree it shouldn't be async just because it's more convenient for browser engines.

Tess: i think it's unfortunate that autoplay policies differ so widely, but also it's an area of innovation where browsers compete to better serve users

Hadley: +1 for the curmugeon's view. Autoplay never meets my user needs.

Peter: we'd rather see one single mechanism... Also: the API shape is weird to me on the media element, just returning a boolean.

Sangwhan: what we have been asked to review is just the chrome proposal. More browsers seem to want the other one. That part is not clear from the request that they sent us.

[some discussion about the quality of the issue and whether it accurately captured the discussion]

Dan: where was the alternative (sync) version documented?

https://github.com/WICG/autoplay/issues/7 https://github.com/WICG/autoplay/pull/8

Hadley: We definitely should steer clear of criticising individuals. But yes, if this is an indication of any one group having an undue influence on the web, like Google having an outsized influence on WICG's activities, then I think we should discuss it. The whole reason we do standards is to bring everyone together and balance out different agendas with consensus.

Tess: there is an issue procecurely we should consider in the TAG... it's unclear if this issue was raised as a dispure resolution vs. a design review request.

David: seems like the template needs an option.

Sangwhan: would it be fair to ask them to provide more info and be clear that maybe TAG could be a tie-breaker?

Tess: it also feels like ... suppose this was being done in a working group and this disagreement happened and everyone threw up their hands. It would be the role of the chairs of the wg to drive consensus. The WICG doesn't do that. It feels weird to come to the TAG [to play that role]. Feels like skipping a step.

Hadley: i think this is important - and one of the issues that comes up when we are hit with so many ideas from chormium that haven't gone through a working group process. then that becomes part of the web platform primarily because they got there first.

Peter: any quick wrap-up? Should we just push back.

Dan: there does seem to be a preference for simplicity.

David: if we're gonna tell them to come back when they're ready. If there is a particular dispute they want us to adjudicate then they need to lay that out.

Hadley: pros/cons; i agree

Tess: i don't think it would work to say go away and come back with an agreement

Hadley: can we have a word with the WICG chairs?

Peter: we could invite the interested parties to the call?

Tess: it's a lot of people..

Tess: A few days ago Peter suggested drafting a reply in-channel to get async consensus. I posted it today, so there's a draft reply in Slack. It looks like several of you have commented; I should revise accordingly before signoff.

Tess: It's long. I was considering separating out the tactical advice that is neither technical nor procedural.

Dan: Feels like something that ought to go to WICG chairs.

Tess: I was there, and we didn't ask the chairs. In this write-up I ask if they did-- although I know they didn't. Need to reword this to be clearer.

Dan: Collective we...

Tess: So not entirely sure about this feedback coming from me, but maybe I should get over it.

Alice: You have some context as to why the WICG chairs weren't involved.

Tess: I don't think it even occurred to anyone. That's not how things work in WICG.

Alice: Maybe reword as "like you, it didn't occur to me there, but..."

Tess: yeah, that sounds good

Tess: So hopefully a bit of tweaking and can resolve async in channel with a 24 hour window or something.

Dan: Yeah, don't need to wait until next week's call. Unless there are other objections.

Alice: I wrote a quick comment in Slack -- I don't have full context but I got some offline -- but it seems to me that they've expressed some frustration that other browsers are saying "we can implement this as synchronous" whereas unwillingness to do so is being read as arbitrary whereas it's not.

Tess: they had a clear technical rationale.

Alice: I think they haven't done a clear job of communicating the cost to users in the Chrome implementation of it being synchronous. (Priority of constituencies.) They conveyed to me, vaguely, that there's a cost to users.

Tess: Recollection: cost to users that's a consequence of design decisions that were implementation details that weren't necessary to the feature.

Alice: Though those aren't arbitrary. Reasons that seem important to them to design it that way.

Dan: Is there a disagreement about who the users are in this discussion?

Tess: I don't think so. People looking at websites.

Dan: OK, will revisit on next call

Tess: We talked about this on a recent telcon, I have yet to update my feedback on the TAG review based on that telcon feedback. Will do so soon.

Dan: Bumping to f2f.