Merge branch 'sync-d35baee3' of https://github.com/javascript-tutorial/fa.javascript.info

� Conflicts:
�	1-js/02-first-steps/04-variables/article.md
�	1-js/06-advanced-functions/04-var/article.md
�	2-ui/2-events/02-bubbling-and-capturing/article.md

Author: mehradsadeghi

1-js/06-advanced-functions/04-var/article.md

@@ -13,7 +13,17 @@ In the very first chapter about [variables](info:variables), we mentioned three
 2. `const`
 3. `var`
 
+<<<<<<< HEAD
+`let` and `const` behave exactly the same way in terms of Lexical Environments.
+
+But `var` is a very different beast, that originates from very old times. It's generally not used in modern scripts, but still lurks in the old ones.
+
+If you don't plan meeting such scripts you may even skip this chapter or postpone it, but then there's a chance that it bites you later.
+
+From the first sight, `var` behaves similar to `let`. That is, declares a variable:
+=======
 The `var` declaration is similar to `let`. Most of the time we can replace `let` by `var` or vice-versa and expect things to work:
+>>>>>>> d35baee32dcce127a69325c274799bb81db1afd8
 
 ```js run
 var message = "Hi";
@@ -28,11 +38,11 @@ On the other hand, it's important to understand differences when migrating old s
 
 ## "var" has no block scope
 
-Variables, declared with `var`, are either function-wide or global. They are visible through blocks.
+`var` variables are either function-wide or global, they are visible through blocks.
 
 For instance:
 
-```js run
+```js
 if (true) {
   var test = true; // use "var" instead of "let"
 }
@@ -42,19 +52,7 @@ alert(test); // true, the variable lives after if
 */!*
 ```
 
-As `var` ignores code blocks, we've got a global variable `test`.
-
-If we used `let test` instead of `var test`, then the variable would only be visible inside `if`:
-
-```js run
-if (true) {
-  let test = true; // use "let"
-}
-
-*!*
-alert(test); // Error: test is not defined
-*/!*
-```
+If we used `let test` on the 2nd line, then it wouldn't be visible to `alert`. But `var` ignores code blocks, so we've got a global `test`.
 
 The same thing for loops: `var` cannot be block- or loop-local:
 
@@ -70,7 +68,7 @@ alert(i); // 10, "i" is visible after loop, it's a global variable
 
 If a code block is inside a function, then `var` becomes a function-level variable:
 
-```js run
+```js
 function sayHi() {
   if (true) {
     var phrase = "Hello";
@@ -80,11 +78,14 @@ function sayHi() {
 }
 
 sayHi();
-alert(phrase); // Error: phrase is not defined (Check the Developer Console)
+alert(phrase); // Error: phrase is not defined
 ```
 
 As we can see, `var` pierces through `if`, `for` or other code blocks. That's because a long time ago in JavaScript blocks had no Lexical Environments. And `var` is a remnant of that.
 
+<<<<<<< HEAD
+## "var" are processed at the function start
+=======
 ## "var" tolerates redeclarations
 
 If we declare the same variable with `let` twice in the same scope, that's an error:
@@ -106,14 +107,15 @@ alert(user); // John
 ```
 
 ## "var" variables can be declared below their use
+>>>>>>> d35baee32dcce127a69325c274799bb81db1afd8
 
 `var` declarations are processed when the function starts (or script starts for globals).
 
 In other words, `var` variables are defined from the beginning of the function, no matter where the definition is (assuming that the definition is not in the nested function).
 
 So this code:
 
-```js run
+```js
 function sayHi() {
   phrase = "Hello";
 
@@ -123,12 +125,11 @@ function sayHi() {
   var phrase;
 */!*
 }
-sayHi();
 ```
 
 ...Is technically the same as this (moved `var phrase` above):
 
-```js run
+```js
 function sayHi() {
 *!*
   var phrase;
@@ -138,12 +139,11 @@ function sayHi() {
 
   alert(phrase);
 }
-sayHi();
 ```
 
 ...Or even as this (remember, code blocks are ignored):
 
-```js run
+```js
 function sayHi() {
   phrase = "Hello"; // (*)
 
@@ -155,7 +155,6 @@ function sayHi() {
 
   alert(phrase);
 }
-sayHi();
 ```
 
 People also call such behavior "hoisting" (raising), because all `var` are "hoisted" (raised) to the top of the function.
@@ -275,11 +274,11 @@ In all the above cases we declare a Function Expression and run it immediately.
 
 ## Summary
 
-There are two main differences of `var` compared to `let/const`:
+There are two main differences of `var`:
 
-1. `var` variables have no block scope, they are visible minimum at the function level.
-2. `var` declarations are processed at function start (script start for globals).
+1. Variables have no block scope, they are visible minimum at the function level.
+2. Variable declarations are processed at function start.
 
 There's one more very minor difference related to the global object, that we'll cover in the next chapter.
 
-These differences make `var` worse than `let` most of the time. Block-level variables is such a great thing. That's why `let` was introduced in the standard long ago, and is now a major way (along with `const`) to declare a variable.
+These differences are actually a bad thing most of the time. First, we can't create block-local variables. And hoisting just creates more space for errors. So, for new scripts `var` is used exceptionally rarely.

2-ui/2-events/02-bubbling-and-capturing/article.md

@@ -108,7 +108,7 @@ Sometimes `event.stopPropagation()` creates hidden pitfalls that later may becom
 
 For instance:
 
-1. We create a nested menu. Each submenu handles clicks on its elements and calls `stopPropagation` so that the outer menu won't trigger.
+1. We create a nested menu. Each submenu handles clicks on its elements and calls `stopPropagation` so that outer menu don't trigger.
 2. Later we decide to catch clicks on the whole window, to track users' behavior (where people click). Some analytic systems do that. Usually the code uses `document.addEventListener('click'…)` to catch all clicks.
 3. Our analytic won't work over the area where clicks are stopped by `stopPropagation`. Sadly, we've got a "dead zone".
 
@@ -130,29 +130,24 @@ Here's the picture of a click on `<td>` inside a table, taken from the specifica
 
 ![](eventflow.svg)
 
-That is: for a click on `<td>` the event first goes through the ancestors chain down to the element (capturing phase), then it reaches the target and triggers there (target phase), and then it goes up (bubbling phase), calling handlers on its way.
+That is: for a click on `<td>` the event first goes through the ancestors chain down to the element (capturing), then it reaches the target, and then it goes up (bubbles), calling handlers on its way.
 
 **Before we only talked about bubbling, because the capturing phase is rarely used. Normally it is invisible to us.**
 
 Handlers added using `on<event>`-property or using HTML attributes or using two-argument `addEventListener(event, handler)` don't know anything about capturing, they only run on the 2nd and 3rd phases.
 
-To catch an event on the capturing phase, we need to set the handler `capture` option to `true`:
+To catch an event on the capturing phase, we need to set the 3rd argument of `addEventListener` to `true`.
 
-```js
-elem.addEventListener(..., {capture: true})
-// or, just "true" is an alias to {capture: true}
-elem.addEventListener(..., true)
-```
-
-There are two possible values of the `capture` option:
+There are two possible values for that optional last argument:
 
 - If it's `false` (default), then the handler is set on the bubbling phase.
 - If it's `true`, then the handler is set on the capturing phase.
 
-
 Note that while formally there are 3 phases, the 2nd phase ("target phase": the event reached the element) is not handled separately: handlers on both capturing and bubbling phases trigger at that phase.
 
-Let's see both capturing and bubbling in action:
+If one puts capturing and bubbling handlers on the target element, the capture handler triggers last in the capturing phase and the bubble handler triggers first in the bubbling phase.
+
+Let's see it in action:
 
 ```html run autorun height=140 edit
 <style>
@@ -180,39 +175,32 @@ The code sets click handlers on *every* element in the document to see which one
 
 If you click on `<p>`, then the sequence is:
 
+<<<<<<< HEAD
+1. `HTML` -> `BODY` -> `FORM` -> `DIV` -> `P` (capturing phase, the first listener), and then:
+2. `P` -> `DIV` -> `FORM` -> `BODY` -> `HTML` (bubbling phase, the second listener).
+=======
 1. `HTML` -> `BODY` -> `FORM` -> `DIV` (capturing phase, the first listener):
 2. `P` (target phase, triggers two times, as we've set two listeners: capturing and bubbling)
 3. `DIV` -> `FORM` -> `BODY` -> `HTML` (bubbling phase, the second listener).
+>>>>>>> d35baee32dcce127a69325c274799bb81db1afd8
 
-There's a property `event.eventPhase` that tells us the number of the phase on which the event was caught. But it's rarely used, because we usually know it in the handler.
-
-```smart header="To remove the handler, `removeEventListener` needs the same phase"
-If we `addEventListener(..., true)`, then we should mention the same phase in `removeEventListener(..., true)` to correctly remove the handler.
-```
-
-````smart header="Listeners on same element and same phase run in their set order"
-If we have multiple event handlers on the same phase, assigned to the same element with `addEventListener`, they run in the same order as they are created:
-
-```js
-elem.addEventListener("click", e => alert(1)); // guaranteed to trigger first
-elem.addEventListener("click", e => alert(2));
-```
-````
+Please note that `P` shows up two times: at the end of capturing and at the start of bubbling.
 
+There's a property `event.eventPhase` that tells us the number of the phase on which the event was caught. But it's rarely used, because we usually know it in the handler.
 
 ## Summary
 
-When an event happens -- the most nested element where it happens gets labeled as the "target element" (`event.target`).
+The event handling process:
 
-- Then the event moves down from the document root to `event.target`, calling handlers assigned with `addEventListener(..., true)` on the way (`true` is a shorthand for `{capture: true}`).
-- Then handlers are called on the target element itself.
-- Then the event bubbles up from `event.target` up to the root, calling handlers assigned using `on<event>` and `addEventListener` without the 3rd argument or with the 3rd argument `false/{capture:false}`.
+- When an event happens -- the most nested element where it happens gets labeled as the "target element" (`event.target`).
+- Then the event first moves from the document root down to the `event.target`, calling handlers assigned with `addEventListener(...., true)` on the way.
+- Then the event moves from `event.target` up to the root, calling handlers assigned using  `on<event>` and `addEventListener` without the 3rd argument or with the 3rd argument `false`.
 
 Each handler can access `event` object properties:
 
 - `event.target` -- the deepest element that originated the event.
 - `event.currentTarget` (=`this`) -- the current element that handles the event (the one that has the handler on it)
-- `event.eventPhase` -- the current phase (capturing=1, target=2, bubbling=3).
+- `event.eventPhase` -- the current phase (capturing=1, bubbling=3).
 
 Any event handler can stop the event by calling `event.stopPropagation()`, but that's not recommended, because we can't really be sure we won't need it above, maybe for completely different things.