"create an event" doesn't work for certain UI events

[domenic]

https://dom.spec.whatwg.org/commit-snapshots/26cfadd185649915bb73d147c8a7a41335cb7ab0/#constructing-events

Consider KeyboardEvent. The problem is that there are many elements in EventModifierInit (which KeyboardEventInit derives from) which are not attributes. So that's not great.

One way to try to fix this would be something like trying to invoke the constructor with the default value, instead of just setting the attributes? And then we assume that the override defined in https://w3c.github.io/uievents/#event-constructors is good enough?

[annevk]

Can't they simply define their own constructor?

[domenic]

You mean, define their own version of "create an event"? I haven't checked, but it seems probable that e.g. HTML uses "create an event" to create mouse events... we'd have to go update HTML and any other specs to use the new UI events "create an event" instead of the DOM "create an event", if that's what you're suggesting.

[annevk]

Maybe we should just inline https://w3c.github.io/uievents/#event-constructors as a legacy exception?

[domenic]

I like that idea. @garykac, thoughts?

[garykac]

Do you mean moving this algorithm snippet:

if Mouse or Keyboard event
  foreach EventModifierInit argument
    ...

into the DOM spec (and removing section 3.6 from UIEvents), or having UIEvents expose an function that the DOM spec would call?

The advantage of the latter is that it will be easier for me to modify the parts related to the "key modifier names", which is something that I need to do.

[annevk]

We could do the latter as well, provided it's somehow limited to these event classes. I mainly want to dissuade others from trying to copy that pattern, although I guess we should consult with some implementers to make sure this doesn't happen in more places before we commit.

[domenic]

I guess the main idea is to make https://dom.spec.whatwg.org/commit-snapshots/26cfadd185649915bb73d147c8a7a41335cb7ab0/#constructing-events work for UI events too. We should be able to do so in a way that calls out to UI events so you can maintain the steps there, mostly.

So concretely I think the best thing would be to add to UI events an algorithm "initialize a mouse or keyboard event from a initialization dictionary" (better name welcome) which takes an event and a dictionary.

Then DOM's constructor algorithm can branch and perform the current step 4 only for non-mouse/keyboard events, calling out to UI event's "initialize a mouse or keyboard event from a initialization dictionary" for those cases. The same for DOM's "create an event" algorithm step 4.

How does that sound?

[annevk]

Would be great if @smaug----, @dtapuska, and @cdumez could review that suggestion.

[domenic]

I mean it's mostly spec factoring so I'm not sure why they'd need to do so? But sure, the more eyes the merrier.

[annevk]

I want to know if these are the only special classes.

[annevk]

So given what we need for "relatedTargets" (see #585) I'm thinking the event constructor calls an internal algorithm that by default is a no-op. (We might want to define it works for inheritance somehow too.)

That way we construct the object, then for the dictionary members we set those dictionary members that have a corresponding internal slot on the object. Then we call that internal algorithm which can handle the remainder, e.g., setting relatedTargets based on the provided relatedTarget, or the much more complicated equivalent operation for Touch Events.

It seems this should work for keyboard events too. We'd recommend against relying on this algorithm without filing an issue against this repository for advice, or some such.

[domenic]

Although the general direction seems right, isn't part of the problem that the init dicts for certain UI events, there is no corresponding internal slot/property? I guess maybe if you checked for the slot first it'd be ok.

[annevk]

Yeah, we'd check if there's a slot, and if there's not just leave it be and hope the internal algorithm handles it. That's what we need for relatedTarget for instance, which would be backed by relatedTargets.

[annevk]

I've done an initial step here: #603.

How exactly do we deal with subclasses here? I think each event class needs to have some associated steps that by default don't do anything. Then when constructing an event we call these steps for each class in the chain?