Understanding and communicating the support of events in implementations is complicated. Taking the "keydown" event an example, there are many different facets of it:

• Event type: will an event with type "keydown" be created and fired by the browser?
  • Where these foo_event should be isn't always clear or consistent. Example: cut_event vs. oncut
• Event interface: does that event use the KeyboardEvent interface?
• Event handler IDL attribute: is the onkeydown IDL attribute supported, and on which interfaces?
  • HTML defines GlobalEventHandlers, but such EventHandler attributes are defined on most interfaces inheriting from EventTarget.
• Event handler content attribute: is the onkeydown content attributes supported, and on which elements? Both HTML and SVG define event handler content attributes:
  • https://html.spec.whatwg.org/multipage/indices.html#ix-event-handlers
  • https://svgwg.org/svg2-draft/attindex.html#RegularAttributes

Unfortunately, all four facets can come apart:

• Events being fired but onfoo IDL attributes being missing (very common)
• The reverse situation, where onfoo is supported despite "foo" never being fired, also happens.
• Events being fired, but as Event and not a more specialized FooEvent.
• The event handler content attributes being missing (relatively rare, but happened historically)

These situations are generally not handled well in BCD, and because only event interface and event handler IDL attribute can be detected with simple feature detection, it's often come up in #6369.

What I believe we need:

• Guidelines for where foo_event entries should be and what they communicate to data consumers.
• Guidelines or agreement on how to communicate a mismatch between especially cut_event and oncut entries.
  • Should there be notes on both, and what should they say?
  • Since this has happened so much but is usually fixed after some time, how do we avoid cluttering up the data with notes?

@Elchi3 @ddbeck @sideshowbarker @vinyldarkscratch