Merge branch 'master' of https://github.com/iliakan/javascript-tutorial-en

Author: iliakan

1-js/01-getting-started/1-intro/article.md

@@ -67,12 +67,12 @@ The examples of such restrictions are:
 
     Modern browsers allow it to work with files, but the access is limited and only provided if the user does certain actions, like "dropping" a file into a browser window or selecting it via an `<input>` tag.
 
-    There are ways to interact with camera/microphone and other devices, but they require an explicit user's permission. So a JavaScript-enabled page may not sneakily enable a web-camera, observe the surroundings and send the information to the [NSA](https://en.wikipedia.org/wiki/National_Security_Agency).
+    There are ways to interact with camera/microphone and other devices, but they require a user's explicit permission. So a JavaScript-enabled page may not sneakily enable a web-camera, observe the surroundings and send the information to the [NSA](https://en.wikipedia.org/wiki/National_Security_Agency).
 - Different tabs/windows generally do not know about each other. Sometimes they do, for example when one window uses JavaScript to open the other one. But even in this case, JavaScript from one page may not access the other if they come from different sites (from a different domain, protocol or port).
 
     That is called a "Same Origin Policy". To workaround that, *both pages* must contain a special JavaScript code that handles data exchange.
 
-    The limitation is again for user's safety. A page from `http://anysite.com` which a user has opened occasionaly must not be able to open or access another browser tab with the URL `http://gmail.com` and steal information from there.
+    The limitation is again for user's safety. A page from `http://anysite.com` which a user has opened occasionally must not be able to open or access another browser tab with the URL `http://gmail.com` and steal information from there.
 - JavaScript can easily communicate over the net to the server where the current page came from. But its ability to receive data from other sites/domains is crippled. Though possible, it requires the explicit agreement (expressed in HTTP headers) from the remote side. Once again, that's safety limitations.
 
 ![](limitations.png)

1-js/01-getting-started/3-devtools/article.md

@@ -29,9 +29,9 @@ It looks somewhat like this:
 The exact look of developer tools depends on your version of Chrome. It changes from time to time, but should be similar.
 
 - Here we can see the red-colored error message. In this case the script contains an unknown "lalala" command.
-- On the right, there is a clickable link to the source `bug.html:12` with the line number where the error has occured.
+- On the right, there is a clickable link to the source `bug.html:12` with the line number where the error has occurred.
 
-Below the error message there is a blue `>` symbol. It marks a "command line" where we can type JavaScript commands and press `key:Enter` to run them (`key:Shift+Enter` to input multiline commands).
+Below the error message there is a blue `>` symbol. It marks a "command line" where we can type JavaScript commands and press `key:Enter` to run them (`key:Shift+Enter` to input multi-line commands).
 
 Now we can see errors and that's enough for the start. We'll be back to developer tools later and cover debugging more in-depth in the chapter <info:debugging-chrome>.
 

1-js/02-first-steps/04-variables/article.md

@@ -141,7 +141,7 @@ It may be interesting to know that there also exist [functional](https://en.wiki
 
 In such languages, once the value is stored "in the box" -- it's there forever. If we need to store something else -- the language forces to create a new box (declare a new variable), we can't reuse the old one.
 
-Though it may seem a little bit odd at the first sight, these languages are quite capable of serious development. More than that, there are areas like parallel computations where this limitation infers certain benefits. Studying of such a language (even if not planning to use it soon) is recommended to broaden the mind.
+Though it may seem a little bit odd at first sight, these languages are quite capable of serious development. More than that, there are areas like parallel computations where this limitation infers certain benefits. Studying of such a language (even if not planning to use it soon) is recommended to broaden the mind.
 ```
 
 ## Variable naming [#variable-naming]
@@ -277,7 +277,7 @@ Benefits:
 
 When should we use capitals for a constant, and when -- name them normally? Let's make that clear.
 
-Being a "constant" just means that the value never changes. But there are constants that are known prior to execution (like a hexadimal value for red), and there are those that are *calculated* in run-time, during the execution, but do not change after the assignment.
+Being a "constant" just means that the value never changes. But there are constants that are known prior to execution (like a hexadecimal value for red), and there are those that are *calculated* in run-time, during the execution, but do not change after the assignment.
 
 For instance:
 ```js
@@ -290,7 +290,7 @@ In other words, capital-named constants are only used as aliases for "hard-coded
 
 ## Name things right
 
-Talking about variables, there's one more exteremely important thing.
+Talking about variables, there's one more extremely important thing.
 
 Please name the variables sensibly. Take time to think if needed.
 

1-js/02-first-steps/08-comparison/article.md

@@ -178,7 +178,7 @@ Yeah, mathematically that's strange. The last result states that "`null` is equa
 
 The reason is that an equality check `==` and comparisons `> < >= <=` work differently. Comparisons convert `null` to a number, hence treat it as `0`. That's why (3) `null >= 0` is true and (1) `null > 0` is false.
 
-From the other hand, the equality check `==` for `undefined` and `null` works by the rule, without any conversions. They equal each other and don't equal anything else. That's why (2) `null == 0` is false.
+On the other hand, the equality check `==` for `undefined` and `null` works by the rule, without any conversions. They equal each other and don't equal anything else. That's why (2) `null == 0` is false.
 
 ### An incomparable undefined
 
@@ -192,7 +192,7 @@ alert( undefined == 0 ); // false (3)
 
 Why does it dislike a zero so much? Always false!
 
-We've got such result, because:
+We've got these results because:
 
 - Comparisons `(1)` and `(2)` return `false` because `undefined` gets converted to `NaN`. And `NaN` is a special numeric value which returns `false` for all comparisons.
 - The equality check `(3)` returns `false`, because `undefined` only equals `null` and no other value.
@@ -201,7 +201,7 @@ We've got such result, because:
 
 Why did we observe these examples? Should we remember these pecularities all the time? Well, not really. Actually, these tricky things will gradually become familiar over the time, but there's a solid way to evade any problems with them.
 
-Just treat any comparison with `undefined/null` except the strict equality `===` with an exceptional care.
+Just treat any comparison with `undefined/null` except the strict equality `===` with exceptional care.
 
 Don't use comparisons `>= > < <=` with a variable which may be `null/undefined`, unless you are really sure what you're doing. If a variable can have such values, then check for them separately.
 

1-js/06-advanced-functions/03-closure/article.md

@@ -15,7 +15,7 @@ Different languages behave differently here, in this chapter we cover JavaScript
 
 ## A couple of questions
 
-Let's formulate two questions for the seed, and then study internal mechanics piece-by-piece, so that you'll be able to answer these questions and more complex ones in the future.
+Let's formulate two questions for the seed, and then study the internal mechanics piece-by-piece, so that you'll be able to answer these questions and more complex ones in the future.
 
 1. The function `sayHi` uses an external variable `name`. When the function runs, which value of these two it's going to use?
 
@@ -176,7 +176,7 @@ sayHi(); // Pete
 
 The execution flow of the code above:
 
-1. The global Lexical Envrionment has `name: "John"`.
+1. The global Lexical Environment has `name: "John"`.
 2. At the line `(*)` the global variable is changed, now it has `name: "Pete"`.
 3. When the function `say()`, is executed and takes `name` from outside. Here that's from the global Lexical Environment where it's already `"Pete"`.
 
@@ -565,7 +565,7 @@ Lexical Environment objects that we've been talking about are subjects to same m
       return function() { alert(value); };
     }
 
-    // 3 functions in array, every of them links to LexicalEnvrironment
+    // 3 functions in array, every of them links to Lexical Environment
     // from the corresponding f() run
     //         LE   LE   LE
     let arr = [f(), f(), f()];

1-js/07-object-oriented-programming/01-property-descriptors/article.md

@@ -143,7 +143,7 @@ user.name = "Alice"; // Error
 
 ## Non-enumerable
 
-Now let's a custom `toString` to `user`.
+Now let's add a custom `toString` to `user`.
 
 Normally, a built-in `toString` for objects is non-enumerable, it does not show up in `for..in`. But if we add `toString` of our own, then by default it shows up in `for..in`.