This is unachievable as of now.

• ReSpec does not support data-dfn-type=event https://github.com/w3c/respec/issues/3197
• Specs does not use data-dfn-for for mixins, instead they use it for the base interfaces (e.g. HTML) or even concepts (e.g. IndexedDB). The mixin case is solvable in types-web side but the concept case is not.

This should be doable since https://github.com/w3c/respec/issues/3197 is merged. Cases like IndexedDB should hopefully be able to be special-cased.

Okay, that just gives the list of events (which is already mostly covered by event handler properties except a few exceptions e.g. DOMContentLoaded), not the event interfaces they use.

@foolip, have you got some idea for this? Probably related to foolip/mdn-bcd-collector#799.

Listing all event interfaces can be done by listing all interfaces inheriting from Event, or in practice anything ending with "Event".

What doesn't exist is a machine-readable definition of is what event types (like "mousemove") exist, what their event interface is and what kind of objects they can be fired at, whether the events bubble, etc.

What is the minimum you need for this project?

Listing all event interfaces can be done by listing all interfaces inheriting from Event, or in practice anything ending with "Event".

What doesn't exist is a machine-readable definition of is what event types (like "mousemove") exist, what their event interface is and what kind of objects they can be fired at, whether the events bubble, etc.

What is the minimum you need for this project?

The first two items are required. The third one is probably also needed to actually map them to the IDL interfaces. I think that's all, additional data e.g. bubbling is not used.

Can you say a bit more about how this data is used? Is it to infer what the type of the event argument for an event callback is, to allow code completion and other nice things? Is the type of the event target used in this type inference?

Does https://html.spec.whatwg.org/multipage/indices.html#events-2 have all the needed information for the events defined in HTML? If so a path forward here could be to formalize that and add such tables to other specs too.

Can you say a bit more about how this data is used? Is it to infer what the type of the event argument for an event callback is, to allow code completion and other nice things? Is the type of the event target used in this type inference?

Currently the code scans the properties of the interface that return EventHandler to get the list:

[Exposed=Window]
interface Foo {
  attribute EventHander onbar; // uses BarEvent
  attribute EventHander onbaz; // uses BazEvent
};

// note that this should get BarEvent/BazEvent but IDL does not provide that info
interface FooEventMap {
  "bar": Event;
  "baz": Event;
}

interface Foo {
  // Same here
  onbar: ((this: Foo, ev: Event) => any) | null;
  onbaz: ((this: Foo, ev: Event) => any) | null;
  addEventListener<K extends keyof FooEventMap>(type: K, listener: (this: Foo, ev: FooHandlersEventMap[K]) => any, options?: boolean | AddEventListenerOptions): void;
  addEventListener(type: string, listener: EventListener, options?: boolean | AddEventListenerOptions): void;
  removeEventListener<K extends keyof FooEventMap>(type: K, listener: (this: FooHandlers, ev: FooHandlersEventMap[K]) => any, options?: boolean | EventListenerOptions): void;
  removeEventListener(type: string, listener: EventListener, options?: boolean | EventListenerOptions): void;
}

Here, the intention here is to map those properties to the event interfaces they use.

Does https://html.spec.whatwg.org/multipage/indices.html#events-2 have all the needed information for the events defined in HTML?

Things become more complicated when those properties are defined in a mixin or a parent interface and the spec only says the corresponding events fire on a child interface, as HTML currently does. But generally yes, the table helps.