This recommendation should be definitely corected relative to the current specification of WHATWG

[ArkadiuszMichalski]

Recently, there have been a few things repaired that further enhancing interoperability (like clean up DOMTokenList/DOMSettableTokenList, correct HTMLCollection.namedItem, EventTarget.removeEventListener, missing some aliases in Document and Attr) and others already closed: https://github.com/whatwg/dom/commits

Without that W3C version will only introduce unnecessary confusion, without coverage in any implementation. There are other inconsistencies in this specification, just look:
"The characterSet attribute's getter and inputEncoding attribute's getter must run these steps:" << but inputEncoding not exist in IDL and is mentioned in the deleted stuff, btw. gbk in table is not linked (but can be).

[marcoscaceres]

Perhaps we should shut down the issue tracker for this repo and point people to file bugs at the WHATWG one. It will be really confusing if things get fixed in one but not the other. Then upstream changes can be merged into this one.

[marcoscaceres]

@plehegar please consider this a formal request from the WICG. This is causing us issues now:
WICG/EventListenerOptions#49

We need a plan for merging in upstream changes on a more regular interval.

[plehegar]

I'm bringing this up to the attention of the Web Platform chairs and anyone else who is willing to help here. I certainly welcome ideas on how to move forward.

[yongsheng]

This is an all-in-one issue. we'll split these issues and address them one by one.

[frivoal]

@plehegar @marcoscaceres The WebPlatform WG charter makes it clear that WHATWG DOM is not considered upstream from W3C DOM, and instead the WG intends to maintain independent control over it. There is an intent to "minimize differences [...] that affect interoperability.", but we should not expect the two to ever be in full sync, since that's not a goal of the WG.

Based I do not know how future work that builds upon DOM is supposed to be done.

[marcoscaceres]

The WebPlatform WG charter makes it clear that WHATWG DOM is not considered upstream from W3C DOM,

I'm sorry, but that's LOL (not laughing at you, just the insanity of the situation).

There is an intent to "minimize differences [...] that affect interoperability.", but we should not expect the two to ever be in full sync, since that's not a goal of the WG.

But then reality has to hit hard: it's a fact that no one is implementing the W3C clone. This will bear out demonstratively in the testing (and as has happened with all the forked specs! The've all died). Because of this, the Working Group cannot progress the spec pass CR without undermining its own process, doing significant harm to the W3C's creditability and of the folks that keep arrogantly peddling this approach.

This is continuing to unnecessarily inflame tensions in the community, while wasting cycles that could be better spent on moving the web forward on other specs that the W3C actually controls.

The W3C is doing great work on it's mission to lead the web to its full potential (e.g., service workers, wasm, css grid, etc.). It doesn't need this Working Group to be forking specs and undermining all the great work the rest of the community is doing.

Based I do not know how future work that builds upon DOM is supposed to be done.

Again, we should then stop - and just cite WHATWG DOM. It's really maddening that we insist on this arrogant madness when we should be focusing on making the Web better. It's petty that we keep having the forking fights.

Can we please please please please stop 💔. This is not worth it anymore.

[chaals]

Aside from the meta-issue of rechartering Web Platform, this issue is not particularly actionable, beyond "do the work well".

Closing.