minor fixes

- fix erratas
- fix wrong error message
- add 'run' on runnable example
- add explanation about window.onload property corresponding load event
- add comment about window.onstorage property corresponding storage event
This commit is contained in:
Violet Bora Lee 2020-03-14 07:27:49 +09:00
parent 36737518f8
commit 958cbe72b8
8 changed files with 13 additions and 13 deletions

View file

@ -31,7 +31,7 @@ function func() {
// hence the error // hence the error
*/!* */!*
console.log(x); // ReferenceError: Cannot access 'vx before initialization console.log(x); // ReferenceError: Cannot access 'x' before initialization
let x = 2; let x = 2;
} }

View file

@ -218,7 +218,7 @@ The Function Expression is wrapped with parenthesis `(function {...})`, because
```js run ```js run
// Try to declare and immediately call a function // Try to declare and immediately call a function
function() { // <-- Error: Unexpected token ( function() { // <-- Error: Function statements require a function name
let message = "Hello"; let message = "Hello";

View file

@ -455,7 +455,7 @@ Such properties have their own issues though. In particular, they are not inheri
## "In range" with "has" trap ## "In range" with "has" trap
Let's see more examples.ar Let's see more examples.
We have a range object: We have a range object:

View file

@ -201,7 +201,7 @@ The parent is available as `parentNode`.
For example: For example:
```js ```js run
// parent of <body> is <html> // parent of <body> is <html>
alert( document.body.parentNode === document.documentElement ); // true alert( document.body.parentNode === document.documentElement ); // true

View file

@ -20,7 +20,7 @@ The classes are:
- [EventTarget](https://dom.spec.whatwg.org/#eventtarget) -- is the root "abstract" class. Objects of that class are never created. It serves as a base, so that all DOM nodes support so-called "events", we'll study them later. - [EventTarget](https://dom.spec.whatwg.org/#eventtarget) -- is the root "abstract" class. Objects of that class are never created. It serves as a base, so that all DOM nodes support so-called "events", we'll study them later.
- [Node](http://dom.spec.whatwg.org/#interface-node) -- is also an "abstract" class, serving as a base for DOM nodes. It provides the core tree functionality: `parentNode`, `nextSibling`, `childNodes` and so on (they are getters). Objects of `Node` class are never created. But there are concrete node classes that inherit from it, namely: `Text` for text nodes, `Element` for element nodes and more exotic ones like `Comment` for comment nodes. - [Node](http://dom.spec.whatwg.org/#interface-node) -- is also an "abstract" class, serving as a base for DOM nodes. It provides the core tree functionality: `parentNode`, `nextSibling`, `childNodes` and so on (they are getters). Objects of `Node` class are never created. But there are concrete node classes that inherit from it, namely: `Text` for text nodes, `Element` for element nodes and more exotic ones like `Comment` for comment nodes.
- [Element](http://dom.spec.whatwg.org/#interface-element) -- is a base class for DOM elements. It provides element-level navigation like `nextElementSibling`, `children` and searching methods like `getElementsByTagName`, `querySelector`. A browser supports not only HTML, but also XML and SVG. The `Element` class serves as a base for more specific classes: `SVGElement`, `XMLElement` and `HTMLElement`. - [Element](http://dom.spec.whatwg.org/#interface-element) -- is a base class for DOM elements. It provides element-level navigation like `nextElementSibling`, `children` and searching methods like `getElementsByTagName`, `querySelector`. A browser supports not only HTML, but also XML and SVG. The `Element` class serves as a base for more specific classes: `SVGElement`, `XMLElement` and `HTMLElement`.
- [HTMLElement](https://html.spec.whatwg.org/multipage/dom.html#htmlelement) -- is finally the basic class for all HTML elements. It is inherited by concrete HTML elements: - [HTMLElement](https://html.spec.whatwg.org/multipage/dom.html#htmlelement) -- is finally the basic class for all HTML elements. It is inherited by concrete HTML elements:
- [HTMLInputElement](https://html.spec.whatwg.org/multipage/forms.html#htmlinputelement) -- the class for `<input>` elements, - [HTMLInputElement](https://html.spec.whatwg.org/multipage/forms.html#htmlinputelement) -- the class for `<input>` elements,
- [HTMLBodyElement](https://html.spec.whatwg.org/multipage/semantics.html#htmlbodyelement) -- the class for `<body>` elements, - [HTMLBodyElement](https://html.spec.whatwg.org/multipage/semantics.html#htmlbodyelement) -- the class for `<body>` elements,
@ -36,7 +36,7 @@ It gets properties and methods as a superposition of (listed in inheritance orde
- `HTMLInputElement` -- this class provides input-specific properties, - `HTMLInputElement` -- this class provides input-specific properties,
- `HTMLElement` -- it provides common HTML element methods (and getters/setters), - `HTMLElement` -- it provides common HTML element methods (and getters/setters),
- `Element` -- provides generic element methods, - `Element` -- provides generic element methods,
- `Node` -- provides common DOM node properties,. - `Node` -- provides common DOM node properties,
- `EventTarget` -- gives the support for events (to be covered), - `EventTarget` -- gives the support for events (to be covered),
- ...and finally it inherits from `Object`, so "plain object" methods like `hasOwnProperty` are also available. - ...and finally it inherits from `Object`, so "plain object" methods like `hasOwnProperty` are also available.

View file

@ -249,7 +249,7 @@ For instance:
```smart header="Computed and resolved values" ```smart header="Computed and resolved values"
There are two concepts in [CSS](https://drafts.csswg.org/cssom/#resolved-values): There are two concepts in [CSS](https://drafts.csswg.org/cssom/#resolved-values):
1. A *computed* style value is the value after all CSS rules and CSS inheritance is applied, as the result of the CSS cascade. It can look like `height:1em` or `font-size:125%`. 1. A *computed* style value is the value after all CSS rules and CSS inheritance is applied, as the result of the CSS cascade. It can look like `height:1em` or `font-size:125%`.
2. A *resolved* style value is the one finally applied to the element. Values like `1em` or `125%` are relative. The browser takes the computed value and makes all units fixed and absolute, for instance: `height:20px` or `font-size:16px`. For geometry properties resolved values may have a floating point, like `width:50.5px`. 2. A *resolved* style value is the one finally applied to the element. Values like `1em` or `125%` are relative. The browser takes the computed value and makes all units fixed and absolute, for instance: `height:20px` or `font-size:16px`. For geometry properties resolved values may have a floating point, like `width:50.5px`.
A long time ago `getComputedStyle` was created to get computed values, but it turned out that resolved values are much more convenient, and the standard changed. A long time ago `getComputedStyle` was created to get computed values, but it turned out that resolved values are much more convenient, and the standard changed.

View file

@ -85,7 +85,7 @@ External style sheets don't affect DOM, so `DOMContentLoaded` does not wait for
But there's a pitfall. If we have a script after the style, then that script must wait until the stylesheet loads: But there's a pitfall. If we have a script after the style, then that script must wait until the stylesheet loads:
```html ```html run
<link type="text/css" rel="stylesheet" href="style.css"> <link type="text/css" rel="stylesheet" href="style.css">
<script> <script>
// the script doesn't not execute until the stylesheet is loaded // the script doesn't not execute until the stylesheet is loaded
@ -108,13 +108,13 @@ So if `DOMContentLoaded` is postponed by long-loading scripts, then autofill als
## window.onload [#window-onload] ## window.onload [#window-onload]
The `load` event on the `window` object triggers when the whole page is loaded including styles, images and other resources. The `load` event on the `window` object triggers when the whole page is loaded including styles, images and other resources. This event is available via the `onload` property.
The example below correctly shows image sizes, because `window.onload` waits for all images: The example below correctly shows image sizes, because `window.onload` waits for all images:
```html run height=200 refresh ```html run height=200 refresh
<script> <script>
window.onload = function() { window.onload = function() { // same as window.addEventListener('load', (event) => {
alert('Page loaded'); alert('Page loaded');
// image is loaded at this time // image is loaded at this time
@ -157,7 +157,7 @@ When the `sendBeacon` request is finished, the browser probably has already left
There's also a `keepalive` flag for doing such "after-page-left" requests in [fetch](info:fetch) method for generic network requests. You can find more information in the chapter <info:fetch-api>. There's also a `keepalive` flag for doing such "after-page-left" requests in [fetch](info:fetch) method for generic network requests. You can find more information in the chapter <info:fetch-api>.
If we want to cancel the transition to another page, we can't do it here. But we can use another event -- `onbeforeunload`. If we want to cancel the transition to another page, we can't do it here. But we can use another event -- `onbeforeunload`.
## window.onbeforeunload [#window.onbeforeunload] ## window.onbeforeunload [#window.onbeforeunload]
@ -277,7 +277,7 @@ Page load events:
- Images and other resources may also still continue loading. - Images and other resources may also still continue loading.
- 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 `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 `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`. - 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: - `document.readyState` is the current state of the document, changes can be tracked in the `readystatechange` event:
- `loading` -- the document is loading. - `loading` -- the document is loading.
- `interactive` -- the document is parsed, happens at about the same time as `DOMContentLoaded`, but before it. - `interactive` -- the document is parsed, happens at about the same time as `DOMContentLoaded`, but before it.

View file

@ -202,7 +202,7 @@ If both windows are listening for `window.onstorage`, then each one will react o
```js run ```js run
// triggers on updates made to the same storage from other documents // triggers on updates made to the same storage from other documents
window.onstorage = event => { window.onstorage = event => { // same as window.addEventListener('storage', () => {
if (event.key != 'now') return; if (event.key != 'now') return;
alert(event.key + ':' + event.newValue + " at " + event.url); alert(event.key + ':' + event.newValue + " at " + event.url);
}; };