Use gender neutral pronouns

This commit is contained in:
Ben James 2018-08-02 15:15:35 +01:00
parent ded121f974
commit e4a4426ff1
24 changed files with 37 additions and 37 deletions

View file

@ -4,7 +4,7 @@ importance: 5
# Catch links in the element
Make all links inside the element with `id="contents"` ask the user if he really wants to leave. And if he doesn't then don't follow.
Make all links inside the element with `id="contents"` ask the user if they really want to leave. And if they don't then don't follow.
Like this:

View file

@ -175,7 +175,7 @@ Now if you double-click on "Unselectable", it doesn't get selected. Seems to wor
...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?
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.
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 them to do it. So this solution is not that good.
What we want is to prevent the selection on double-click, that's it.

View file

@ -10,7 +10,7 @@ Each event may be useful:
- `DOMContentLoaded` event -- DOM is ready, so the handler can lookup DOM nodes, initialize the interface.
- `load` event -- additional resources are loaded, we can get image sizes (if not specified in HTML/CSS) etc.
- `beforeunload/unload` event -- the user is leaving: we can check if the user saved the changes and ask him whether he really wants to leave.
- `beforeunload/unload` event -- the user is leaving: we can check if the user saved the changes and ask them whether they really want to leave.
Let's explore the details of these events.

View file

@ -6,7 +6,7 @@ importance: 5
Write a function that shows a tooltip over an element only if the visitor moves the mouse *over it*, but not *through it*.
In other words, if the visitor moves the mouse on the element and stopped -- show the tooltip. And if he just moved the mouse through fast, then no need, who wants extra blinking?
In other words, if the visitor moves the mouse on the element and stopped -- show the tooltip. And if they just moved the mouse through fast, then no need, who wants extra blinking?
Technically, we can measure the mouse speed over the element, and if it's slow then we assume that it comes "over the element" and show the tooltip, if it's fast -- then we ignore it.

View file

@ -23,7 +23,7 @@
// JavaScript does not get the "keyup" event
// and pressed set will keep assuming that the key is pressed
// so, to evade "sticky" keys, we reset the status
// if the user wants to run the hotkey again - let him press all keys again
// if the user wants to run the hotkey again - let them press all keys again
pressed.clear();
func();

View file

@ -4,7 +4,7 @@ importance: 4
# Load visible images
Let's say we have a slow-speed client and want to save his mobile traffic.
Let's say we have a slow-speed client and want to save their mobile traffic.
For that purpose we decide not to show images immediately, but rather replace them with placeholders, like this:

View file

@ -6,7 +6,7 @@ importance: 5
Create a function `showPrompt(html, callback)` that shows a form with the message `html`, an input field and buttons `OK/CANCEL`.
- A user should type something into a text field and press `key:Enter` or the OK button, then `callback(value)` is called with the value he entered.
- A user should type something into a text field and press `key:Enter` or the OK button, then `callback(value)` is called with the value they entered.
- Otherwise if the user presses `key:Esc` or CANCEL, then `callback(null)` is called.
In both cases that ends the input process and removes the form.