Merge pull request #349 from odsantos/update-en-browser-actions

Update "Browser default actions" article

Author: odsantos

2-ui/2-events/04-default-browser-action/article.md

@@ -73,27 +73,24 @@ menu.onclick = function(event) {
 };
 ```
 
-If we omit `return false`, then after our code executes the browser will do its "default action" -- following to the URL in `href`.
+If we omit `return false`, then after our code executes the browser will do its "default action" -- navigating to the URL in `href`. And we don't need that here, as we're handling the click by ourselves.
 
-By the way, using event delegation here makes our menu flexible. We can add nested lists and style them using CSS to "slide down".
-
-
-## Prevent further events
+By the way, using event delegation here makes our menu very flexible. We can add nested lists and style them using CSS to "slide down".
 
+````smart header="Follow-up events"
 Certain events flow one into another. If we prevent the first event, there will be no second.
 
 For instance, `mousedown` on an `<input>` field leads to focusing in it, and the `focus` event. If we prevent the `mousedown` event, there's no focus.
 
-Try to click on the first `<input>` below -- the `focus` event happens. That's normal.
-
-But if you click the second one, there's no focus.
+Try to click on the first `<input>` below -- the `focus` event happens. But if you click the second one, there's no focus.
 
 ```html run autorun
 <input value="Focus works" onfocus="this.value=''">
 <input *!*onmousedown="return false"*/!* onfocus="this.value=''" value="Click me">
 ```
 
 That's because the browser action is canceled on `mousedown`. The focusing is still possible if we use another way to enter the input. For instance, the `key:Tab` key to switch from the 1st input into the 2nd. But not with the mouse click any more.
+````
 
 ## The "passive" handler option
 
@@ -118,21 +115,23 @@ There's an interesting use case for it.
 
 You remember in the chapter <info:bubbling-and-capturing> we talked about `event.stopPropagation()` and why stopping bubbling is bad?
 
-Sometimes we can use `event.defaultPrevented` instead.
+Sometimes we can use `event.defaultPrevented` instead, to signal other event handlers that the event was handled.
 
-Let's see a practical example where stopping the bubbling looks necessary, but actually we can do well without it.
+Let's see a practical example.
 
 By default the browser on `contextmenu` event (right mouse click) shows a context menu with standard options. We can prevent it and show our own, like this:
 
 ```html autorun height=50 no-beautify run
-<button>Right-click for browser context menu</button>
+<button>Right-click shows browser context menu</button>
 
 <button *!*oncontextmenu="alert('Draw our menu'); return false"*/!*>
-  Right-click for our context menu
+  Right-click shows our context menu
 </button>
 ```
 
-Now let's say we want to implement our own document-wide context menu, with our options. And inside the document we may have other elements with their own context menus:
+Now, in addition to that context menu we'd like to implement document-wide context menu.
+
+Upon right click, the closest context menu should show up.
 
 ```html autorun height=80 no-beautify run
 <p>Right-click here for the document context menu</p>
@@ -153,7 +152,7 @@ Now let's say we want to implement our own document-wide context menu, with our
 
 The problem is that when we click on `elem`, we get two menus: the button-level and (the event bubbles up) the document-level menu.
 
-How to fix it? One of solutions is to think like: "We fully handle the event in the button handler, let's stop it" and use `event.stopPropagation()`:
+How to fix it? One of solutions is to think like: "When we handle right-click in the button handler, let's stop its bubbling" and use `event.stopPropagation()`:
 
 ```html autorun height=80 no-beautify run
 <p>Right-click for the document menu</p>
@@ -181,7 +180,7 @@ An alternative solution would be to check in the `document` handler if the defau
 
 
 ```html autorun height=80 no-beautify run
-<p>Right-click for the document menu (fixed with event.defaultPrevented)</p>
+<p>Right-click for the document menu (added a check for event.defaultPrevented)</p>
 <button id="elem">Right-click for the button menu</button>
 
 <script>
@@ -222,7 +221,6 @@ There are many default browser actions:
 - `mousedown` -- starts the selection (move the mouse to select).
 - `click` on `<input type="checkbox">` -- checks/unchecks the `input`.
 - `submit` -- clicking an `<input type="submit">` or hitting `key:Enter` inside a form field causes this event to happen, and the browser submits the form after it.
-- `wheel` -- rolling a mouse wheel event has scrolling as the default action.
 - `keydown` -- pressing a key may lead to adding a character into a field, or other actions.
 - `contextmenu` -- the event happens on a right-click, the action is to show the browser context menu.
 - ...there are more...
@@ -238,7 +236,7 @@ If the default action was prevented, the value of `event.defaultPrevented` becom
 ```warn header="Stay semantic, don't abuse"
 Technically, by preventing default actions and adding JavaScript we can customize the behavior of any elements. For instance, we can make a link `<a>` work like a button, and a button `<button>` behave as a link (redirect to another URL or so).
 
-But we should generally keep the semantic meaning of HTML elements. For instance, `<a>` should preform navigation, not a button.
+But we should generally keep the semantic meaning of HTML elements. For instance, `<a>` should perform navigation, not a button.
 
 Besides being "just a good thing", that makes your HTML better in terms of accessibility.