[whatwg/dom] Missing machinery for associated Event data (Issue #1328)

### What is the issue with the DOM Standard?

In https://github.com/whatwg/html/pull/9841#discussion_r1834134022 @annevk and I discussed some of the spec around the `CommandEvent` as part of `command/commandfor`. The `source` attribute on the `CommandEvent` performs logic to retarget the element based on its `currentTarget`, however while this works in browsers it doesn't work so well in the spec. To quote the conversation there:

> @annevk: How does this work when it's initialized synthetically? There's also a wrapping problem.

> @keithamus: I am unsure how to answer this, as far as I know this just kind of works? If the `currentTarget` is an element and its tree-root is not the same as the document then it'll be retargeted to the tree-root host. Therefore `currentTarget` won't return elements that cross a shadow boundary. Is this not the correct way to express that in the spec?

> @annevk: If the source attribute is initialized to something it can't also have a getter. I'm not really sure how to make this work specification-wise. This would require some kind of internal slot, but since those are not formalized it would currently clash with how event constructors are defined...


What is missing is the ability to have associated event data. @annevk mentioned in a DM:

> I have an idea of sorts that I think can work. I used to think we needed IDL stuff for this, but we can do this by defining an internal "extras" map on event objects that we fill with these data members.

Hopefully I've captured this properly, and we have an idea of what needs to happen to proceed. 

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

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