Re: [whatwg/dom] Allow custom "get the parent" algorithms for EventTargets (#583)

@LeaVerou What you suggest is how Deno already works.  The code complexity around polyfilling Node is a quite a bit. I've tried it and ended up just wrapping EventTarget instead. 

> This is piggybacking off `Node`, but to write a proper shim for it (I've tried it), you have to implement `Node`, `ChildNode`, `ParentNode`, `Document`. and some others that my escape me at the moment. That would be a lot of work for user agents to include and force them to require support something far more complicated just `EventTarget`

https://github.com/whatwg/dom/issues/583#issuecomment-814495296

Looking at my code, I have a bastardization of Node as a shim for the tree, without all the document stuff.

Subclassing between EventTarget and Node is probably better, though we'd have to define what goes in and what doesn't (eg: do we need to include `insertBefore`). 

The only "concern" I can see about passing an EventTarget instead (`new EventTarget(parentEventTarget)`) of an init object is that EventTarget instances can be overloaded with their own properties, and I would want to avoid the possibilty of that custom EventTarget object later conflicting with an `EventTargetInit` property.  For example:

```js
class FooEventTarget extends EventTarget {
  bubbles = false;
}
```

Then if we make an `EventTargetInit` later with `{bubbles: true, parent: foo}` , it would be unclear if they're passing the parent or an EventTarget instance that has a property when doing `new EventTarget(new FooEventTarget())`. 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/583#issuecomment-1753485129
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/583/1753485129@github.com>