Skip to content

Commit 317c89a

Browse files
authored
Typo fixes and some language improvements
1 parent 2a3182a commit 317c89a

File tree

1 file changed

+8
-8
lines changed
  • 2-ui/3-event-details/1-mouse-events-basics

1 file changed

+8
-8
lines changed

2-ui/3-event-details/1-mouse-events-basics/article.md

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -58,7 +58,7 @@ Also we can see the `which` property that allows to detect the mouse button.
5858

5959
## Getting the button: which
6060

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.
6262

6363
It is not used for `click` and `contextmenu` events, because the former happens only on left-click, and the latter -- only on right-click.
6464

@@ -177,7 +177,7 @@ Now if you double-click on "Unselectable", it doesn't get selected. Seems to wor
177177

178178
...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?
179179

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.
181181

182182
What we want is to prevent the selection on double-click, that's it.
183183

@@ -193,7 +193,7 @@ Before...
193193

194194
Now the bold element is not selected on double clicks.
195195

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.
197197

198198
````smart header="Canceling the selection"
199199
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
228228

229229
## Summary
230230

231-
Mouse events have following properties:
231+
Mouse events have the following properties:
232232

233233
- Button: `which`.
234234
- Modifier keys (`true` if pressed): `altKey`, `ctrlKey`, `shiftKey` and `metaKey` (Mac).
235235
- 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)`.
236236

237237
- Window-relative coordinates: `clientX/clientY`.
238-
- Document-relative coordinates: `pageX/clientX`.
238+
- Document-relative coordinates: `pageX/pageY`.
239239

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.
241241

242-
There are several ways, for instance:
243-
1. CSS-property `user-select:none` (with browser prefixes) completely disables it.
242+
There are several ways to do this, for instance:
243+
1. The CSS-property `user-select:none` (with browser prefixes) completely disables text-selection.
244244
2. Cancel the selection post-factum using `getSelection().removeAllRanges()`.
245245
3. Handle `mousedown` and prevent the default action (usually the best).

0 commit comments

Comments
 (0)