Editorial: major cleanup around firing events

[annevk]

There’s no need to state defaults again as that only leads to confusion
when they are not explicitly stated.

[domenic]

This is part of #1713 FYI

[domenic]

Additional cleanups to do:

• #downloading-or-updating-an-application-cache:concept-event-fire
• #downloading-or-updating-an-application-cache:concept-event-fire-2
• #runtime-script-errors-2:concept-event-fire
• #the-storage-event:concept-event-fire
• #the-end:concept-event-fire

Following the dfn popup for dispatch also has many of these cases, where it uses the terminology "does not bubble and is not cancelable" or similar when setting up the event and then dispatching it in a subsequent step. (Many of these cases could probably become "fire" instead of "dispatch" by collapsing some steps... I don't understand why they're separate in most cases. Probably cargo-culting. If you collapse the steps and use "fire", you also can get rid of the "trusted" concept, since trusted is the default for firing.)

• #fire-a-focus-event
• #the-dragevent-interface:concept-event-dispatch
• #unloading-documents:concept-event-dispatch
• #runtime-script-errors:concept-event-dispatch
• #unhandled-promise-rejections:concept-event-dispatch
• #the-hostpromiserejectiontracker-implementation:concept-event-dispatch
• #event-firing:concept-event-dispatch
• #event-firing:concept-event-dispatch-2
• #event-stream-interpretation:concept-event-dispatch
• #feedback-from-the-protocol:concept-event-dispatch
• #feedback-from-the-protocol:concept-event-dispatch-2
• #posting-messages:concept-event-dispatch
• #message-ports:concept-event-dispatch
• #broadcasting-to-other-browsing-contexts:concept-event-dispatch
• #worker-processing-model:concept-event-dispatch
• #shared-workers-and-the-sharedworker-interface:concept-event-dispatch

In general I think you'll want to Ctrl+F for "does not bubble" and "is not cancelable".

[domenic]

This should use the new style for bubbles and cancelable, I think

[domenic]

"initialized to state" would be a bit nicer while you're here

[domenic]

This one has "This event must not bubble, must not be cancelable, and has no default action." which should be removed.

[annevk]

So I mainly removed trusted and then did some cleanup alongside. I guess we could turn this into something bigger, but then I should probably first redesign "fire an event" on the DOM side and make all that work too.

[domenic]

Hmm OK. I think it'd be nice to land more at once but if it'd be helpful to work incrementally then I think just addressing the line comments (without doing the additional cleanups on the IDs I listed) would be fine. Maybe with a commit message that notes this is just an initial pass and there are many other call sites that need updating.

[annevk]

I'm happy to make this bigger. I already created a PR for DOM to redesign "fire an event": whatwg/dom#344. Would be best to review and land that first, then work on this.

[annevk]

Document object's Window object or Document object's relevant global object? Kept the former for now, should maybe be a separate change for all instances (not that many). (I also found one instance of the latter not being correctly linked. Apparently wattsi does start complaining, but only after you have two instances of data-x-less <span>s. Having said that, perhaps they should all be data-x-less and we just use an ID on the <dfn>, as the term is rather unique anyway.)

[annevk]

FWIW, anything in the AppCache section I rather not touch until we decide what to do there. It seems better for that to either be removed, or be cleaned up altogether and integrated with Fetch if we decide to keep it.

[domenic]

I'd rather clean up the appcache ones as well. It's a mechanical transformation with no normative impact. We don't gain anything by making it inconsistent with the rest of the spec.

[annevk]

This is ready for review now. I tried filing follow up issues whenever I saw something bogus.

[domenic]

Missed:

• #the-dragevent-interface:concept-events-trusted
• #feedback-from-the-protocol:concept-events-trusted
• "When a key event is to be routed in a top-level browsing context, the user agent must run the following steps:" should link to fire and use the return value. Probably a preexisting issue.

Typos:

• "intiialized" (many times)
• "Let report be the result of firing an event named invalid at this element, with the attribute initialized to true." at #the-constraint-validation-api:concept-event-fire-2

Other:

• Add data-x-href to firing and dispatching so they link to DOM instead of to HTML. Maybe move them to the dependencies section.
• Add a note to "Firing a simple event named e" saying this is going away and should not be used, and link to Remove "Firing a simple event named e" #1887?
• Sometimes you say "using StorageEvent", sometimes "that uses the TrackEvent interface". This doesn't necessarily seem worth fixing but I wanted to make sure you were aware.
• Lots of places use "If the event is canceled" or similar phrasing. Maybe file a follow-up to use the return values instead, or add it to the OP of Event dispatch/firing should reuse DOM terms better #1713.
• "Fire a DND event" should probably return the value of dispatching, and could probably consolidate its create/dispatch steps into a single fire step.
• #unloading-documents:concept-event-dispatch could consolidate creation and dispatching steps

Commit message should mention the follow-ups if possible.

[annevk]

Commit message prep:

Editorial: major cleanup around firing and dispatching events

This aligns firing and dispatching of events with updated terminology in the DOM Standard. Among the changes:

* A lot less usage of "default action" which isn't really a thing. Instead we make use of the return value of the fire and dispatch algorithms.
* Instead of saying things bubble or are cancelable we initialize the attributes as such.
* We now use the legacy target override flag rather than supplying a named argument.

This fixes #1713, but plenty of follow up issues remain:

* #805 for the remainder of "default action" usage
* #1394 for updating synthetic click events
* #1887 for removing "fire a simple event" usage
* #1893 for updating when checkboxes get checked
* #1900 for figuring out if event dispatch requires more hooks
* #1912 for revisiting isTrusted usage
* #1913 for updating synthetic mouse events
* #1922 for making more events composed

[annevk]

When a key event is to be routed in a top-level browsing context

This should use dispatch actually, since the event is already created, we're just rerouting it. This is another thing that is monkey patching the non-existing UI events specification.

[annevk]

Add a note to "Firing a simple event named e" saying this is going away and should not be used, and link to #1887?

I plan on not doing this given that we have a volunteer. If that doesn't pan out I'll make it happen.

[annevk]

#unloading-documents:concept-event-dispatch could consolidate creation and dispatching steps

This is #1900.

[annevk]

Lots of places use "If the event is canceled" or similar phrasing.

"is canceled" and "not canceled" don't give many results, some are in notes. I will clean it up, but not those I found inside the "Activation" section as that will largely disappear with #1394.

[annevk]

"Fire a DND event" should probably return the value of dispatching, and could probably consolidate its create/dispatch steps into a single fire step.

This actually looks complicated, since it does steps after dispatch. I wonder if the text as written is even correct. I'm not planning on fixing this here.

[annevk]

So we might want to open an issue for the DND processing model (or the larger lack of user interaction specification), but other than that I once again think I'm done.

[domenic]

Missing closing tags