CFC to migrate to the Web Platform WG

[marcoscaceres]

It seems that EventListenerOptions has gotten wide backing from browser vendors, with Blink, Gecko, WebKit implementations underway or shipping 🎉 .

This makes it a good candidate to migrate to the Web Platform WG for formal standardization.

People working on the spec, WDYT? How much more work is needed to migrate this work?

@jacobrossi, I know Edge folks had some concerns, but can the Edge team live with the current design?

[marcoscaceres]

Actually, I'm not even sure this would go into the Web Platform WG. Suggestions of where to formally standardize welcome... or, I perhaps this would just live in WHATWG DOM?

[jacobrossi]

Web Platform WG would be the right place IMO.

[annevk]

It's already part of the DOM Standard. Does not really have to move anywhere, definitely not Web Platform WG though. Not sure how that makes sense.

[RByers]

We long ago agreed that this feature integrated directly into the core of DOM and so could only be specified properly as part of the DOM spec (rather than try to monkey patch it). I still REALLY want to see a venue for DOM spec standardization that includes all the major browser vendors, but that's an ongoing discussion much broader than ELO (so let's not go into it here).

@jacobrossi do you disagree? Are you saying you think we should revive my old monkey-patch spec for EventListenerOptions?

[jacobrossi]

No, we shouldn't revive the monkey patch spec. You're right @RByers , it doesn't add much value over the explainer.

I'm also not interested in having yet another one-off rehash of WHATWG vs W3C WG drama here. We won't solve that here. Pretending that the WHATWG DOM "Standard" would be a sufficient solution to a W3C group's issue discussing advancement in W3C's own process is just a waste of our engineering time.

So until a single, proper DOM spec exists that meets the needs of the major browser contributors and web developers, I suppose we might as well table this issue as-is. If and when we decide to implement this before that exists, we'll just implement it based on the WICG explainer and the Chrome implementation as a "defacto" standard like anything else (-webkit* APIs etc).

[marcoscaceres]

Sorry, it was not my intention to open up the WHATWG/W3C can of worms.

As a step, I've asked the W3C to at least stop having its own issue tracker for the W3C copy of the DOM spec - and just merge the upstream (w3c/dom#3 (comment)). I hate that solution as much as anyone, but I think it at least solves the "standard" problem if we can continuously keep publishing RECs with new features such as this one.

There are other things we can add, like making it clear that the upstream WHATWG is the canonical version, etc.... you've all heard this stuff before.

[RByers]

Yep, it sounds like we're all on the same page here given the current relaity - thanks!

[marcoscaceres]

Reopening this, as I want to go through the process of doing the intent to migrate (Chair's duty and part of our Charter). I'll send a PR with the administrative stuff and then take the fight to the W3C directly to make sure W3C's DOM copy gets regularly updated.

I'll work with the Co-Chairs (@yoavweiss, @cwilso) and the W3C to come up with something we are all happy with.

Please feel free to unsubscribe/mute from this bug - politics ahead. Will try to keep the noise to a minimum and out of this repo.

[RByers]

Ah, ok - that's fine with me, thanks! Let me know if there's anything I can do to help.

There are a lot of links out there pointing here (eg. to the explainer) so if you move the repo please also setup redirects.