EventListenerOptions and passive event listeners - move to WICG?

For some time we’ve been discussing a proposed extension to DOM events called passive event listeners, which is designed to enable touch and wheel scroll performance optimizations. This has now been integrated into the WHATWG DOM spec. However, to properly enable discussion beyond WHATWG participants, there is also a rough standalone spec.

To begin to bring this work into the W3C process, I propose we import the EventListenerOptions repository into the WICG. Thoughts?

+1

Same

I don’t actually understand what that means.

WHATWG specifications are developed through direct open community participation in the form of github issue-tracker discussions and pull requests.

So I genuinely don’t understand what discussions aren’t already enabled by the existing infrastructure of the actual existing spec, or what kind of discussions would be enabled by creating a forked copy of it. I mean, the WICG also just uses github repos and issue-trackers and pull requests, right? (As many or most W3C working groups now do.)

I realize there’s also this Discourse instance as an additional discussion forum. But you obviously don’t need to fork a copy of a somebody else’s spec just to have a discussion about it here.

—Mike

We’re not talking about forking a spec here. Just, during the initial brainstorm / consensus-building phase, having a document that describes the rough design in a way that provides the minimal IP protection necessary for all W3C members to feel like they can freely provide their feedback before any vendor ships the API and the web becomes locked into it.

I’m really not qualified to drive a whole W3C vs. WHATWG debate, so I’d rather not turn this thread into that. The key question here is whether there’s any reason why it would be a bad idea for this document to be moved into the WICG?

In this specific case, we got some late public feedback from Microsoft that definitely would have happened 5+ months earlier if I had been proactive about bringing this to the WICG. We all value the input of the Edge engineers in web platform design, so (regardless of the ideal standards development world we all want) pragmatically I consider it my mistake that I didn’t do this sooner and I’d like to rectify that.

Actually, Mike, that’s not the entirety of the WICG’s value. The WICG does some work to ensure that any contributors to the spec are WICG members - and submitters of any PRs have signed a contributor license, for example. That’s a significant benefit in terms of IP provenance, and makes it a lot more tenable for lawyercats in terms of participation.

As with Rick, I don’t want to turn this into a WHATWG-vs-W3C discussion. But I’m happy to go on about why we created the WICG and what value it adds in terms of IP and governance (without an overabundance of Process).

AFAICT, the repo is not a copy of “somebody else’s spec”, but a re-publishing of previous work, in order to enable participation and feedback from members which lawyers require a CLA.

I don’t see a problem here, as long as once the incubation phase is done, we will make it clear that the document published on that repo is obsolete.

+1 from me. Yay to passive events!!!

I was wondering when WICG would revert back to classic W3C form of copying and re-branding WHATWG specs. I guess it begins now. And they were doing such a good job with original work so far!

These are two phrases for the same thing.

Well, it has all the usual problems of forking. Trying to constrain it to a time-limited period is indeed helpful, but in the meantime, all the harm persists.

I find it very unfortunate that when Rick wants to brainstorm about his ideas in the WICG he is actively dissuaded from doing so by folks bringing a non-technical W3C/WHATWG debate instead. WICG is an open community group and anyone should feel free to bring their ideas here. And yes, this does mean that they can take whatever they contributed into a different group and bring it here. If the proposal gets improved from it, that’s great. Now, can we please go back to making a great Open Web Platform or is this thread going to turn into a thread of your average Internet commentor?

I think it’s important to actively dissuade people from doing harmful things. Casting shade about “average internet commentors” doesn’t make it any less harmful.

We all of course want what’s best for the web platform. Some people think the best way to do that is copying others’ specs, and some of us disagree and think doing so is actively harmful to the web platform. There’s no need to try to shut down discussion on this point of disagreement.

Talking with a few folks offline, I think there’s a nice happy middle-ground in this case.

The monkey patch spec wasn’t adding any information beyond the explainer, and so was redundant while providing only a source of consternation and potential confusion. So I deleted it. The key information in this repo is contained in the explainer and issues (both open and now closed), and moving those to WICG seems uncontentious.

Any final concerns before we import this repo?

That’s really great to hear, Rick. Thanks for taking the steps to reduce confusion. If it will make some people more comfortable to have discussions in WICG/ instead of RByers/ or whatwg/, then as long as there is no pretention that the spec is there, that helps a lot. We can always proxy the results of their discussions over to the official standard’s issue tracker.

The finally advice I’d have is to add a prominent section to the explainer or readme saying that this is discussing a feature of the DOM Standard specified in https://dom.spec.whatwg.org/#dom-eventtarget-addeventlistener, https://dom.spec.whatwg.org/#observing-event-listeners, and https://dom.spec.whatwg.org/#dom-event-preventdefault among a few other places that can be found by following definitions; that this is serving as an additional place (in addition to the standard’s issue tracker) for certain parties to discuss the feature; and that any decisions made or statements found in the documents there are not normative until they have made it into the DOM Standard. Reducing confusion is the name of the game here.

I agree explainers should be updated to point clearly to specs and implementation status when things get that far. I’ve made a few tweaks along the lines you suggest to the README and Explainer opening. I don’t think it’s necessary to add big warnings like “not normative” - there’s clearly no spec here (no IDL), the risk of confusion should be low now.

I’ve now imported the repo here. I’m happy to continue to make tweaks as desired and grant push access to others involved in the discussion.