Merge branch 'master' of github.com:javascript-tutorial/en.javascript.info into sync-3c934b5a

Author: iliakan

1-js/02-first-steps/16-function-expressions/article.md

@@ -34,7 +34,7 @@ In more advanced situations, that we'll come across later, a function may be cre
 
 ## Function is a value
 
-Let's reiterate: no matter how the function is created, a function is a value. Both examples above store a function is `sayHi` variable.
+Let's reiterate: no matter how the function is created, a function is a value. Both examples above store a function in the `sayHi` variable.
 
 We can even print out that value using `alert`:
 

1-js/04-object-basics/08-symbol/article.md

@@ -161,7 +161,7 @@ for (let key in user) alert(key); // name, age (no symbols)
 alert( "Direct: " + user[id] );
 ```
 
-[Object.keys(user)](mdn:js/Object/keys) also ignores them. That's a part of the general "hiding symbolic properties" principle. If another script or a library loops over our object, it won't unexpectedly access a symbolic property.
+[Object.keys(user)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/keys) also ignores them. That's a part of the general "hiding symbolic properties" principle. If another script or a library loops over our object, it won't unexpectedly access a symbolic property.
 
 In contrast, [Object.assign](mdn:js/Object/assign) copies both string and symbol properties:
 

1-js/05-data-types/12-json/article.md

@@ -27,7 +27,7 @@ Luckily, there's no need to write the code to handle all this. The task has been
 
 ## JSON.stringify
 
-The [JSON](http://en.wikipedia.org/wiki/JSON) (JavaScript Object Notation) is a general format to represent values and objects. It is described as in [RFC 4627](http://tools.ietf.org/html/rfc4627) standard. Initially it was made for JavaScript, but many other languages have libraries to handle it as well.  So it's easy to use JSON for data exchange when the client uses JavaScript and the server is written on Ruby/PHP/Java/Whatever.
+The [JSON](http://en.wikipedia.org/wiki/JSON) (JavaScript Object Notation) is a general format to represent values and objects. It is described as in [RFC 4627](https://tools.ietf.org/html/rfc4627) standard. Initially it was made for JavaScript, but many other languages have libraries to handle it as well.  So it's easy to use JSON for data exchange when the client uses JavaScript and the server is written on Ruby/PHP/Java/Whatever.
 
 JavaScript provides methods:
 

1-js/08-prototypes/01-prototype-inheritance/article.md

@@ -54,7 +54,7 @@ alert( rabbit.eats ); // true (**)
 alert( rabbit.jumps ); // true
 ```
 
-Here the line `(*)` sets `animal` to be a prototype of `rabbit`.
+Here the line `(*)` sets `animal` to be the prototype of `rabbit`.
 
 Then, when `alert` tries to read property `rabbit.eats` `(**)`, it's not in `rabbit`, so JavaScript follows the `[[Prototype]]` reference and finds it in `animal` (look from the bottom up):
 
@@ -287,7 +287,7 @@ for(let prop in rabbit) alert(prop); // jumps, then eats
 */!*
 ```
 
-If that's not what we want, and we'd like to exclude inherited properties, there's a built-in method [obj.hasOwnProperty(key)](mdn:js/Object/hasOwnProperty): it returns `true` if `obj` has its own (not inherited) property named `key`.
+If that's not what we want, and we'd like to exclude inherited properties, there's a built-in method [obj.hasOwnProperty(key)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty): it returns `true` if `obj` has its own (not inherited) property named `key`.
 
 So we can filter out inherited properties (or do something else with them):
 

1-js/09-classes/01-class/article.md

@@ -118,7 +118,7 @@ alert(Object.getOwnPropertyNames(User.prototype)); // constructor, sayHi
 
 ## Not just a syntactic sugar
 
-Sometimes people say that `class` is a "syntactic sugar" (syntax that is designed to make things easier to read, but doesn't introduce anything new), because we could actually declare the same without `class` keyword at all:
+Sometimes people say that `class` is a "syntactic sugar" (syntax that is designed to make things easier to read, but doesn't introduce anything new), because we could actually declare the same thing without using the `class` keyword at all:
 
 ```js run
 // rewriting class User in pure functions

5-network/05-fetch-crossorigin/article.md

@@ -207,10 +207,11 @@ Some time ago no one could even imagine that a webpage could make such requests.
 
 So, to avoid misunderstandings, any "unsafe" request -- that couldn't be done in the old times, the browser does not make such requests right away. First, it sends a preliminary, so-called "preflight" request, to ask for permission.
 
-A preflight request uses the method `OPTIONS`, no body and two headers:
+A preflight request uses the method `OPTIONS`, no body and three headers:
 
 - `Access-Control-Request-Method` header has the method of the unsafe request.
 - `Access-Control-Request-Headers` header provides a comma-separated list of its unsafe HTTP-headers.
+- `Origin` header tells from where the request came. (such as `https://javascript.info`)
 
 If the server agrees to serve the requests, then it should respond with empty body, status 200 and headers:
 

6-data-storage/01-cookie/article.md

@@ -96,38 +96,42 @@ Usually, we should set `path` to the root: `path=/` to make the cookie accessibl
 
 A domain defines where the cookie is accessible. In practice though, there are limitations. We can't set any domain.
 
-By default, a cookie is accessible only at the domain that set it. So, if the cookie was set by `site.com`, we won't get it at `other.com`.
+**There's no way to let a cookie be accessible from another 2nd-level domain, so `other.com` will never receive a cookie set at `site.com`.**
+
+It's a safety restriction, to allow us to store sensitive data in cookies that should be available only on one site.
 
-...But what's more tricky, we also won't get the cookie at a subdomain `forum.site.com`!
+By default, a cookie is accessible only at the domain that set it.
+
+Please note, by default a cookie is also not shared to a subdomain as well, such as `forum.site.com`.
 
 ```js
-// at site.com
+// if we set a cookie at site.com website...
 document.cookie = "user=John"
 
-// at forum.site.com
+// ...we won't see it at forum.site.com
 alert(document.cookie); // no user
 ```
 
-**There's no way to let a cookie be accessible from another 2nd-level domain, so `other.com` will never receive a cookie set at `site.com`.**
+...But this can be changed. If we'd like to allow subdomains like `forum.site.com` to get a cookie set at `site.com`, that's possible.
 
-It's a safety restriction, to allow us to store sensitive data in cookies, that should be available only on one site.
+For that to happen, when setting a cookie at `site.com`, we should explicitly set the `domain` option to the root domain: `domain=site.com`. Then all subdomains will see such cookie.
 
-...But if we'd like to allow subdomains like `forum.site.com` to get a cookie, that's possible. When setting a cookie at `site.com`, we should explicitly set the `domain` option to the root domain: `domain=site.com`:
+For example:
 
 ```js
 // at site.com
 // make the cookie accessible on any subdomain *.site.com:
-document.cookie = "user=John; domain=site.com"
+document.cookie = "user=John; *!*domain=site.com*/!*"
 
 // later
 
 // at forum.site.com
 alert(document.cookie); // has cookie user=John
 ```
 
-For historical reasons, `domain=.site.com` (a dot before `site.com`) also works the same way, allowing access to the cookie from subdomains. That's an old notation and should be used if we need to support very old browsers.
+For historical reasons, `domain=.site.com` (with a dot before `site.com`) also works the same way, allowing access to the cookie from subdomains. That's an old notation and should be used if we need to support very old browsers.
 
-So, the `domain` option allows to make a cookie accessible at subdomains.
+To summarize, the `domain` option allows to make a cookie accessible at subdomains.
 
 ## expires, max-age
 
@@ -180,7 +184,7 @@ With this option, if a cookie is set by `https://site.com`, then it doesn't appe
 // assuming we're on https:// now
 // set the cookie to be secure (only accessible over HTTPS)
 document.cookie = "user=John; secure";
-```  
+```
 
 ## samesite
 
@@ -247,7 +251,7 @@ But anything more complicated, like a network request from another site or a for
 
 If that's fine for you, then adding `samesite=lax` will probably not break the user experience and add protection.
 
-Overall, `samesite` is a great option. 
+Overall, `samesite` is a great option.
 
 There's a drawback: