"asynchronous" doesn't mean anything in particular on its own, does it?

Well, we use it all the time to indicate a set of steps can be run simultaneously with JavaScript without violating run to completion semantics (due to the only JavaScript observable thing that is done being task queuing).

I've had a few times that implementers or members of TC39 got confused by that notion so I think it would be good if we explained it explicitly. So that whenever we say:

"Return /x/, but continue running these steps asynchronously."

or

"Run /x/ asynchronously."

"asynchronous" can be cross-referenced to that explanation.

In "Return /x/, but continue running these steps asynchronously", the word "asynchronously" just means "in parallel". Should we just replace use of the word with that alternative term?

I think that is clearer, but still warrants an explanation as to what it means with respect to JavaScript and what this parallel set of steps can do.

Why with respect to JS? I don't understand what JS has to do with anything here. What would the explanation look like?

I'm basically not sure what we should say here. If we're just quoting the dictionary, then we're not providing value, IMHO.

(In reply to Ian 'Hixie' Hickson from comment #5)
> Why with respect to JS? I don't understand what JS has to do with anything
> here. What would the explanation look like?

It's not understood by specification editors that for a section that's marked asynchronous, they can't just change properties of an object.

It's not understood by reviewers what the implication of such a section is or how you'd polyfill it in JavaScript (you can't and it's worth calling that out).

What I want to be crystal clear somehow is that such a set of steps must not mutate state, must not mutate objects (e.g. an ArrayBuffer), ..., and can only use tasks to synchronize state, mutate objects, etc. (And when doing so should make that observable through promises or events.)

Well you _can_ just change properties of an object; <img>.complete for example changes that way, IIRC.

Sounds like what you want is a "how to write specs" guide, which describes good design patterns like not introducing race conditions.

I'm happy to go through and remove all uses of "synchronous" and "asynchronous" if you want, but I'm not sure what else would be appropriate to do in the HTML spec. Please advise regarding what you think we should do and why HTML is the appropriate place for it, if it is.

HTML defines the event loop mechanism for several distinct environments. There's an assumed environment that is not explicitly called out in the specification, which is the user agent environment. Whenever steps can run asynchronously, some code might execute there in parallel with one or more event loops, or as part of the same event loop if the implementation has only one thread.

Making that more explicit would help people understand what "asynchronous" means. I have the feeling that people reading these documents having previously read the JavaScript specification do not really grasp this larger-than-JavaScript model that is in place.

(As an aside, I've also had several instances where having an event loop for that user agent environment would help. So you could do things asynchronously, but still in a defined order. Not having to define such a structure on a per-spec basis would be nice.)

I'm confused. The way "asynchronous" is used in the HTML spec just means "in parallel with", or "on a separate thread" (or fiber, or process, or on a different core, or whatever multithreading paradigm the host environment has). There's no synchronous scheduling mechanism involved here.

I feel like I'm missing some key context. What do you mean by "user agent environment"?

I understand that, and calling that out in more detail would help. That it runs in parallel with JavaScript from the respective event loop and that therefore tasks need to be queued (or promises resolved) to change observable state.

(In implementations those algorithms are typically done on some kind of UA thread that has a notion of scheduling. I was thinking it might be worth to define that, but I should not have conflated that with the original issue.)

> I understand that, and calling that out in more detail would help. That it
> runs in parallel with JavaScript from the respective event loop and that
> therefore tasks need to be queued (or promises resolved) to change
> observable state.

Not just JavaScript. All tasks.

I don't understand who the target audience is here. Implementors, or other spec authors? If it's spec authors, then this belongs on the wiki, not in the HTML spec. If it's implementors, then I can certainly add a section defining "in parallel" as meaning "using a separate thread, fiber, process, or whatever" and then move from "asynchronous" to "in parallel".


> (In implementations those algorithms are typically done on some kind of UA
> thread that has a notion of scheduling. I was thinking it might be worth to
> define that, but I should not have conflated that with the original issue.)

Unless there's a black-box observable difference, I don't see why we'd define it. In theory, all the things that are done in parallel in the spec are done in separate threads, not queued on some single other thread. (In particular, they don't yield.)

I think it would help both. Definitely going forward if more algorithms get implemented straight in JS in some engines.

Checked in as WHATWG revision r8799.
Check-in comment: Stop using the word 'asynchronously', and reduce usage of the word 'synchronous'.
https://html5.org/tools/web-apps-tracker?from=8798&to=8799