You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 2-ui/3-event-details/1-mouse-events-basics/article.md
+8-8Lines changed: 8 additions & 8 deletions
Original file line number
Diff line number
Diff line change
@@ -58,7 +58,7 @@ Also we can see the `which` property that allows to detect the mouse button.
58
58
59
59
## Getting the button: which
60
60
61
-
Click-related events always have the `which` property that allows to get the button.
61
+
Click-related events always have the `which` property, which allows to get the exact mouse button.
62
62
63
63
It is not used for `click` and `contextmenu` events, because the former happens only on left-click, and the latter -- only on right-click.
64
64
@@ -177,7 +177,7 @@ Now if you double-click on "Unselectable", it doesn't get selected. Seems to wor
177
177
178
178
...But there is a potential problem! The text became truly unselectable. Even if a user starts the selection from "Before" and ends with "After", the selection skips "Unselectable" part. Do we really want to make our text unselectable?
179
179
180
-
Most of time, we don't. A user may have valid reasons to select the text, for copying or other needs. That may be disturbing if we don't allow him to do it. So the solution is not that good.
180
+
Most of time, we don't. A user may have valid reasons to select the text, for copying or other needs. That may be inconvenient if we don't allow him to do it. So this solution is not that good.
181
181
182
182
What we want is to prevent the selection on double-click, that's it.
183
183
@@ -193,7 +193,7 @@ Before...
193
193
194
194
Now the bold element is not selected on double clicks.
195
195
196
-
From the other hand, the text inside it is still selectable. The selection should start not on the text itself, but before or after it. Usually that's fine.
196
+
The text inside it is still selectable. However, the selection should start not on the text itself, but before or after it. Usually that's fine though.
197
197
198
198
````smart header="Canceling the selection"
199
199
Instead of *preventing* the selection, we can cancel it "post-factum" in the event handler.
@@ -228,18 +228,18 @@ Surely that can't stop the user from opening HTML-source, but not everyone knows
228
228
229
229
## Summary
230
230
231
-
Mouse events have following properties:
231
+
Mouse events have the following properties:
232
232
233
233
- Button: `which`.
234
234
- Modifier keys (`true` if pressed): `altKey`, `ctrlKey`, `shiftKey` and `metaKey` (Mac).
235
235
- If you want to handle `key:Ctrl`, then don't forget Mac users, they use `key:Cmd`, so it's better to check `if (e.metaKey || e.ctrlKey)`.
236
236
237
237
- Window-relative coordinates: `clientX/clientY`.
238
-
- Document-relative coordinates: `pageX/clientX`.
238
+
- Document-relative coordinates: `pageX/pageY`.
239
239
240
-
In the tasks below it's also important to deal with the selection as an unwanted side-effect of clicks.
240
+
It's also important to deal with text selection as an unwanted side-effect of clicks.
241
241
242
-
There are several ways, for instance:
243
-
1. CSS-property `user-select:none` (with browser prefixes) completely disables it.
0 commit comments