minor changes in grammar
This commit is contained in:
parent
d5f4fe9e18
commit
58c91c3c9f
1 changed files with 9 additions and 9 deletions
|
@ -49,7 +49,7 @@ In the example the `DOMContentLoaded` handler runs when the document is loaded,
|
|||
|
||||
But it doesn't wait for the image to load. So `alert` shows zero sizes.
|
||||
|
||||
At the first sight `DOMContentLoaded` event is very simple. The DOM tree is ready -- here's the event. There are few peculiarities though.
|
||||
At first sight, the `DOMContentLoaded` event is very simple. The DOM tree is ready -- here's the event. There are few peculiarities though.
|
||||
|
||||
### DOMContentLoaded and scripts
|
||||
|
||||
|
@ -75,8 +75,8 @@ In the example above, we first see "Library loaded...", and then "DOM ready!" (a
|
|||
|
||||
```warn header="Scripts that don't block DOMContentLoaded"
|
||||
There are two exceptions from this rule:
|
||||
1. Scripts with `async` attribute that we'll cover [a bit later](info:script-async-defer) don't block `DOMContentLoaded`.
|
||||
2. Scripts that are generated dynamically with `document.createElement('script')` and then added to page also don't block this event.
|
||||
1. Scripts with the `async` attribute, that we'll cover [a bit later](info:script-async-defer), don't block `DOMContentLoaded`.
|
||||
2. Scripts that are generated dynamically with `document.createElement('script')` and then added to the webpage also don't block this event.
|
||||
```
|
||||
|
||||
### DOMContentLoaded and styles
|
||||
|
@ -93,7 +93,7 @@ But there's a pitfall. If we have a script after the style, then that script mus
|
|||
</script>
|
||||
```
|
||||
|
||||
The reason is that the script may want to get coordinates and other style-dependent properties of elements, like in the example above. Naturally, it has to wait for styles to load.
|
||||
The reason for this is that the script may want to get coordinates and other style-dependent properties of elements, like in the example above. Naturally, it has to wait for styles to load.
|
||||
|
||||
As `DOMContentLoaded` waits for scripts, it now waits for styles before them as well.
|
||||
|
||||
|
@ -217,7 +217,7 @@ if (document.readyState == 'loading') {
|
|||
}
|
||||
```
|
||||
|
||||
There's also `readystatechange` event that triggers when the state changes, so we can print all these states like this:
|
||||
There's also the `readystatechange` event that triggers when the state changes, so we can print all these states like this:
|
||||
|
||||
```js run
|
||||
// current state
|
||||
|
@ -272,12 +272,12 @@ The numbers in square brackets denote the approximate time of when it happens. E
|
|||
|
||||
Page load events:
|
||||
|
||||
- `DOMContentLoaded` event triggers on `document` when DOM is ready. We can apply JavaScript to elements at this stage.
|
||||
- The `DOMContentLoaded` event triggers on `document` when the DOM is ready. We can apply JavaScript to elements at this stage.
|
||||
- Script such as `<script>...</script>` or `<script src="..."></script>` block DOMContentLoaded, the browser waits for them to execute.
|
||||
- Images and other resources may also still continue loading.
|
||||
- `load` event on `window` triggers when the page and all resources are loaded. We rarely use it, because there's usually no need to wait for so long.
|
||||
- `beforeunload` event on `window` triggers when the user wants to leave the page. If we cancel the event, browser asks whether the user really wants to leave (e.g we have unsaved changes).
|
||||
- `unload` event on `window` triggers when the user is finally leaving, in the handler we can only do simple things that do not involve delays or asking a user. Because of that limitation, it's rarely used. We can send out a network request with `navigator.sendBeacon`.
|
||||
- The `load` event on `window` triggers when the page and all resources are loaded. We rarely use it, because there's usually no need to wait for so long.
|
||||
- The `beforeunload` event on `window` triggers when the user wants to leave the page. If we cancel the event, browser asks whether the user really wants to leave (e.g we have unsaved changes).
|
||||
- `The unload` event on `window` triggers when the user is finally leaving, in the handler we can only do simple things that do not involve delays or asking a user. Because of that limitation, it's rarely used. We can send out a network request with `navigator.sendBeacon`.
|
||||
- `document.readyState` is the current state of the document, changes can be tracked in the `readystatechange` event:
|
||||
- `loading` -- the document is loading.
|
||||
- `interactive` -- the document is parsed, happens at about the same time as `DOMContentLoaded`, but before it.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue