minor fixes

1-js/11-async/05-promise-api/article.md

@@ -112,7 +112,7 @@ Promise.all(requests)
   ));
 ```
 
-A bigger example with fetching user information for an array of github users by their names (or we could fetch an array of goods by their ids, the logic is same):
+A bigger example with fetching user information for an array of GitHub users by their names (we could fetch an array of goods by their ids, the logic is same):
 
 ```js run
 let names = ['iliakan', 'remy', 'jeresig'];
@@ -134,7 +134,7 @@ Promise.all(requests)
   .then(users => users.forEach(user => alert(user.name)));
 ```
 
-**If any of the promises is rejected, `Promise.all` immediately rejects with that error.**
+**If any of the promises is rejected, the promise returned by `Promise.all` immediately rejects with that error.**
 
 For instance:
 
@@ -155,10 +155,10 @@ If one promise rejects, `Promise.all` immediately rejects, completely forgetting
 
 For example, if there are multiple `fetch` calls, like in the example above, and one fails, other ones will still continue to execute, but `Promise.all` don't watch them any more. They will probably settle, but the result will be ignored.
 
-`Promise.all` does nothing to cancel them, as there's no concept of "cancellation" in promises. In [another chapter](fetch-abort) we'll cover `AbortController` that aims to help with that, but it's not a part of the Promise API.
+`Promise.all` does nothing to cancel them, as there's no concept of "cancellation" in promises. In [another chapter](info:fetch-abort) we'll cover `AbortController` that can help with that, but it's not a part of the Promise API.
 ```
 
-````smart header="`Promise.all(...)` allows non-promise items in `iterable`"
+````smart header="`Promise.all(iterable)` allows non-promise \"regular\" values in `iterable`"
 Normally, `Promise.all(...)` accepts an iterable (in most cases an array) of promises. But if any of those objects is not a promise, it's wrapped in `Promise.resolve`.
 
 For instance, here the results are `[1, 2, 3]`:
@@ -173,8 +173,7 @@ Promise.all([
 ]).then(alert); // 1, 2, 3
 ```
 
-So we are able to pass non-promise values to `Promise.all` where convenient.
-
+So we are able to pass ready values to `Promise.all` where convenient.
 ````
 
 ## Promise.allSettled
@@ -289,4 +288,4 @@ There are 5 static methods of `Promise` class:
     - `value` (if fulfilled) or `reason` (if rejected).
 5. `Promise.race(promises)` -- waits for the first promise to settle, and its result/error becomes the outcome.
 
-Of these five, `Promise.all/allSettled` are the most common in practice.
+Of these five, `Promise.all` is probably the most common in practice.

1-js/11-async/07-microtask-queue/article.md

@@ -21,7 +21,7 @@ That's strange, because the promise is definitely done from the beginning.
 
 Why did the `.then` trigger afterwards? What's going on?
 
-## Microtasks
+## Microtasks queue
 
 Asynchronous tasks need proper management. For that, the standard specifies an internal queue `PromiseJobs`, more often referred to as "microtask queue" (v8 term).
 
@@ -68,7 +68,7 @@ let promise = Promise.reject(new Error("Promise Failed!"));
 promise.catch(err => alert('caught'));
 */!*
 
-// no error, all quiet
+// doesn't run: error handled
 window.addEventListener('unhandledrejection', event => alert(event.reason));
 ```
 
@@ -93,13 +93,13 @@ setTimeout(() => promise.catch(err => alert('caught')), 1000);
 window.addEventListener('unhandledrejection', event => alert(event.reason));
 ```
 
-Now, if you run it, we'll see `Promise Failed!` message first, and then `caught`.
+Now, if you run it, we'll see `Promise Failed!` message first, and then `caught`. 
 
-If we didn't know about microtasks, we could wonder: "Why did `unhandledrejection` happen? We did catch the error!".
+If we didn't know about microtasks queue, we could wonder: "Why did `unhandledrejection` handler run? We did catch the error!".
 
-But now we do know that `unhandledrejection` is generated when the microtask queue is complete: the engine examines promises and, if any of them is in "rejected" state, then the event triggers.
+But now we understand that `unhandledrejection` is generated when the microtask queue is complete: the engine examines promises and, if any of them is in "rejected" state, then the event triggers.
 
-...By the way, the `.catch` added by `setTimeout` also triggers, of course it does, but later, after `unhandledrejection` has already occurred.
+In the example above, `.catch` added by `setTimeout` also triggers, but later, after `unhandledrejection` has already occurred, so that doesn't change anything.
 
 ## Summary