Skip to content

Commit e92386e

Browse files
committed
Update "Browser default actions" article
1 parent 1ffcb4e commit e92386e

File tree

1 file changed

+15
-17
lines changed

1 file changed

+15
-17
lines changed

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

Lines changed: 15 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -73,27 +73,24 @@ menu.onclick = function(event) {
7373
};
7474
```
7575

76-
If we omit `return false`, then after our code executes the browser will do its "default action" -- following to the URL in `href`.
76+
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.
7777

78-
By the way, using event delegation here makes our menu flexible. We can add nested lists and style them using CSS to "slide down".
79-
80-
81-
## Prevent further events
78+
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".
8279

80+
````smart header="Follow-up events"
8381
Certain events flow one into another. If we prevent the first event, there will be no second.
8482
8583
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.
8684
87-
Try to click on the first `<input>` below -- the `focus` event happens. That's normal.
88-
89-
But if you click the second one, there's no focus.
85+
Try to click on the first `<input>` below -- the `focus` event happens. But if you click the second one, there's no focus.
9086
9187
```html run autorun
9288
<input value="Focus works" onfocus="this.value=''">
9389
<input *!*onmousedown="return false"*/!* onfocus="this.value=''" value="Click me">
9490
```
9591
9692
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.
93+
````
9794

9895
## The "passive" handler option
9996

@@ -118,21 +115,23 @@ There's an interesting use case for it.
118115

119116
You remember in the chapter <info:bubbling-and-capturing> we talked about `event.stopPropagation()` and why stopping bubbling is bad?
120117

121-
Sometimes we can use `event.defaultPrevented` instead.
118+
Sometimes we can use `event.defaultPrevented` instead, to signal other event handlers that the event was handled.
122119

123-
Let's see a practical example where stopping the bubbling looks necessary, but actually we can do well without it.
120+
Let's see a practical example.
124121

125122
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:
126123

127124
```html autorun height=50 no-beautify run
128-
<button>Right-click for browser context menu</button>
125+
<button>Right-click shows browser context menu</button>
129126

130127
<button *!*oncontextmenu="alert('Draw our menu'); return false"*/!*>
131-
Right-click for our context menu
128+
Right-click shows our context menu
132129
</button>
133130
```
134131

135-
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:
132+
Now, in addition to that context menu we'd like to implement document-wide context menu.
133+
134+
Upon right click, the closest context menu should show up.
136135

137136
```html autorun height=80 no-beautify run
138137
<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
153152

154153
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.
155154

156-
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()`:
155+
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()`:
157156

158157
```html autorun height=80 no-beautify run
159158
<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
181180

182181

183182
```html autorun height=80 no-beautify run
184-
<p>Right-click for the document menu (fixed with event.defaultPrevented)</p>
183+
<p>Right-click for the document menu (added a check for event.defaultPrevented)</p>
185184
<button id="elem">Right-click for the button menu</button>
186185

187186
<script>
@@ -222,7 +221,6 @@ There are many default browser actions:
222221
- `mousedown` -- starts the selection (move the mouse to select).
223222
- `click` on `<input type="checkbox">` -- checks/unchecks the `input`.
224223
- `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.
225-
- `wheel` -- rolling a mouse wheel event has scrolling as the default action.
226224
- `keydown` -- pressing a key may lead to adding a character into a field, or other actions.
227225
- `contextmenu` -- the event happens on a right-click, the action is to show the browser context menu.
228226
- ...there are more...
@@ -238,7 +236,7 @@ If the default action was prevented, the value of `event.defaultPrevented` becom
238236
```warn header="Stay semantic, don't abuse"
239237
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).
240238
241-
But we should generally keep the semantic meaning of HTML elements. For instance, `<a>` should preform navigation, not a button.
239+
But we should generally keep the semantic meaning of HTML elements. For instance, `<a>` should perform navigation, not a button.
242240
243241
Besides being "just a good thing", that makes your HTML better in terms of accessibility.
244242

0 commit comments

Comments
 (0)