@Josh-Cena @dipikabh Looking at this text ^^^ it seems pretty unhelpful to me - should I as a user of this method need to understand stack frames or microtask? No, no I should not - certainly not for this method where knowing this makes no difference.

This was also discussed in #43973, where we were converging towards something like this:

It is possibly not quite correct, but it captures the main point of the original, which is that these events are synchronous, whereas events generated by the browser are not.

Anyway, my take on this is that something simple here is better or deleting the text entirely, as largely irrelevant to readers.

I'll leave to you, and close the other issue as it was "late to the party".

... or if you leave it to me, I'll just delete this section altogether :-)

The fundamental question is whether there's race—i.e., if it's possible for other jobs to execute in between two event handler executions.

Following @hamishwillee comment about not being too "low-level-ish" (though I argue about his remark regarding microtasks - modern JS developers are familiar with the concept, especially as queueMicrotask is an official API, MDN also has a guide on it (added a link to it in my suggestion), plus the event loop is mentioned - it's just the same amount of "low-level", if not more) I ) and in the spirit of this paragraph being about "native events VS. user events", I now suggest changing to adding this note (while removing that paragraph)

@Josh-Cena @dipikabh Looking at this text ^^^ it seems pretty unhelpful to me - should I as a user of this method need to understand stack frames or microtask? No, no I should not - certainly not for this method where knowing this makes no difference.

This was also discussed in #43973, where we were converging towards something like this:

It is possibly not quite correct, but it captures the main point of the original, which is that these events are synchronous, whereas events generated by the browser are not.

Anyway, my take on this is that something simple here is better or deleting the text entirely, as largely irrelevant to readers.

I'll leave to you, and close the other issue as it was "late to the party".

@hamishwillee I disagree about the comment about should they be familiar with what a microtask is. Yes - they should, queueMicrotask is official API. MDN has this guide: https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide.
The event loop is mentioned - which is an even "lower-level" concept.

I think the questions regarding about whether this paragraph should exist, and if so - is this the right place, are:

• Would a reader of the dispatchEvent page will likely be interested in a quick summary of the differences between "custom and native"? I say: yes.
• What would represent the practical differences? I say: mainly the microtasks difference, the non render between handlers, then I also think the isTrusted.

On the other hand - your last suggestion is short and concise - and does "fix" the technical semantic "mistake" that triggered me to open this PR.

The fundamental question is whether there's race—i.e., if it's possible for other jobs to execute in between two event handler executions.

@Josh-Cena If this is the fundamental question/problem then IMO should be addressed directly rather than highlighting that some things are sync and others are async. I.e. start with the problem.

@yuval-a As a general principle I think we will have to agree to disagree on microtasks - most programmers most of the time do not need to care about that level of detail. Of course it may be that this is a case where the problem can't be explained without them. Fortunately I'm not the reviewer, so I don't need to assess that.

The paragraph on isTrusted seems useful YOu might consider a few words on why it matters (in addition to the link)

@hamishwillee I thought about just mentioning Promises but it sounds too partial.
Anyway, I think the subject of "do we go there?" about Microtasks - is like a "standards/specs" question. I'm not a long-running contributor to MDN - I came here because I was triggered by the phrasing of that paragraph - but do MDN have a formal "standards" document? like a "style guide"? If not, it should - I was going per what I know already exists. But anyway I emphasis again that I think it's very legit to use that term;

1. As I mentioned there's actually an official global method with that term in its name (for me that alone is enough to justify it).
2. Microtasks is the de facto mechanism of "asynchronicity" in Javascript - before it existed it was just "offload to the host browser" for async. To the best of my knowledge adding it was a design choice spawned from: "We need a way to allow these "clean-up/just-before" tasks inside Javascript. It's used for Promise resolve callbacks, but also for Custom Elements reactions, MutationObserver callbacks and likely other stuff. It's a thing in Javascript, like, a major thing.

Anyway, a compromise would be to mention Promises instead and add "Microtasks" parenthesised. Also, I'm leaning more and more towards a note that explains the two different types of events.

This is my next suggestion: