This commit is contained in:
Ilya Kantor 2017-11-01 12:57:35 +03:00
commit 0f1455da90
34 changed files with 132 additions and 132 deletions

View file

@ -55,7 +55,7 @@ let scrollHeight = Math.max(
document.body.clientHeight, document.documentElement.clientHeight
);
alert('Full document width, with scrolled out part: ' + scrollHeight);
alert('Full document height, with scrolled out part: ' + scrollHeight);
```
Why so? Better don't ask. These inconsistencies come from ancient times, not a "smart" logic.

View file

@ -18,7 +18,7 @@ For instance, if the height of the whole HTML document is 2000px, then:
document.documentElement.getBoundingClientRect().top = 0
// window-relative bottom = 2000
// the document is long, so that is probably far beyound the window bottom
// the document is long, so that is probably far beyond the window bottom
document.documentElement.getBoundingClientRect().bottom = 2000
```

View file

@ -12,7 +12,7 @@ Like this:
Please note two important features of the scroll:
1. **The scroll is "elastic".** We can scroll a little beyound the document start or end in some browsers/devices (empty space below is shown, and then the document will automatically "bounces back" to normal).
1. **The scroll is "elastic".** We can scroll a little beyond the document start or end in some browsers/devices (empty space below is shown, and then the document will automatically "bounces back" to normal).
2. **The scroll is imprecise.** When we scroll to page end, then we may be in fact like 0-50px away from the real document bottom.
So, "scrolling to the end" should mean that the visitor is no more than 100px away from the document end.

View file

@ -4,9 +4,9 @@ An element receives a focus when the user either clicks on it or uses the `key:T
Focusing generally means: "prepare to accept the data here", so that's the moment when we can run the code to initialize or load something.
The moment of loosing the focus ("blur") can be even more important. That's when a user clicks somewhere else or presses `key:Tab` to go to the next form field, or there are other means as well.
The moment of losing the focus ("blur") can be even more important. That's when a user clicks somewhere else or presses `key:Tab` to go to the next form field, or there are other means as well.
Loosing the focus generally means: "the data has been entered", so we can run the code to check it or even to save it to the server and so on.
Losing the focus generally means: "the data has been entered", so we can run the code to check it or even to save it to the server and so on.
There are important peculiarities when working with focus events. We'll do the best to cover them here.
@ -14,7 +14,7 @@ There are important peculiarities when working with focus events. We'll do the b
## Events focus/blur
The `focus` event is called on focusing, and `blur` -- when the element looses the focus.
The `focus` event is called on focusing, and `blur` -- when the element loses the focus.
Let's use them for validation of an input field.
@ -90,7 +90,7 @@ It works in all browsers except Firefox ([bug](https://bugzilla.mozilla.org/show
If we enter something into the input and then try to use `key:Tab` or click away from the `<input>`, then `onblur` returns the focus back.
Please note that we can't "prevent loosing focus" by calling `event.preventDefault()` in `onblur`, because `onblur` works *after* the element lost the focus.
Please note that we can't "prevent losing focus" by calling `event.preventDefault()` in `onblur`, because `onblur` works *after* the element lost the focus.
```warn header="JavaScript-initiated focus loss"
A focus loss can occur for many reasons.
@ -214,7 +214,7 @@ So here's another working variant:
## Summary
Events `focus` and `blur` trigger on focusing/loosing focus on the element.
Events `focus` and `blur` trigger on focusing/losing focus on the element.
Their specials are:
- They do not bubble. Can use capturing state instead or `focusin/focusout`.