Event dispatch/firing should reuse DOM terms better

[domenic]

https://html.spec.whatwg.org/#concept-event-fire defines firing an event and dispatching an event, but instead it should just link to the definitions in DOM: https://dom.spec.whatwg.org/#concept-event-fire and https://dom.spec.whatwg.org/#concept-event-dispatch

Things to consider:

• Everywhere I clicked that uses "fire an event" instead says "fire a trusted event". Per DOM, firing an event always makes it trusted, so we should (a) check if any cases it needs to be untrusted, and adjust those to something different; (b) remove "trusted" from all the call sites, as it is redundant.
• DOM should probably be adjusted to make it clear that the caller of "fire an event" can specify the interface, and instead of saying as it currently does "with its cancelable attribute initialized to true", it should encourage us to say (as HTML does) "that is cancelable".
• IMO we should take this opportunity to clean up all redundant "that does not bubble" or "is not cancelable" since those are the defaults anyway. But... that might cause confusion; see <details> 'toggle' simple event bubbling #1533.
• While doing this we should consider cleaning up as many default actions as we can (Spec still talks about "default actions" for events #805), or at least the trivial ones that say "has no default action".

[annevk]

It should encourage us to say (as HTML does) "that is cancelable"

That seems a little weird. Once we have internal slots as a thing, we basically want HTML to set some internal slots, right? I'm not sure why [[cancelable]] and [[bubbles]] should be privileged above all other internal slots and have magic addressing.

I agree with everything else and would like to put some time in some of this as it helps address some issues in DOM too.

[domenic]

I think we don't need to have double-bracket notation to have internal slots. IMO the existing "that is cancelable" is a way of setting the already-existing implicit cancelable internal slot. (Most places would state this as "associated cancelable flag", but I guess DOM does not at the moment.)

I don't feel strongly either way though, and I see you've already made the changes in #1886 in your preferred direction, so I'm happy to go along with that. Will try to review that later today.

[annevk]

Sure, agreed on the double brackets, but we also have isTrusted, source, etc. Would we turn those into terms of art too?

(And the main reason DOM doesn't define these as concepts at the moment is that I'd much rather have IDL do this automatically as internal slots (whatever the notation). Otherwise each new event basically needs a bunch of boilerplate to define its concepts and all the "automagic" language we have around the constructor would become way more involved or break down.)

[domenic]

We already did for "trusted", I think? And yeah, I can see how events could be a special case given how they have such a generic internal structure/construction algorithm/re-initialization algorithm.

[annevk]

Well, I'm just holding out with events due to their nature, but once we have automatic internal slots I'd use them everywhere. Not having to define "associated concepts" would be terrific.

HTML does have something specific for trusted indeed although defined by reference to the isTrusted attribute so I'm not sure that's helping much. (And again, there's many more members.)