improvements
This commit is contained in:
parent
55ba66021b
commit
76b0616727
5 changed files with 21 additions and 23 deletions
|
@ -63,7 +63,7 @@ user.sayHi(); // Hello!
|
||||||
```smart header="Object-oriented programming"
|
```smart header="Object-oriented programming"
|
||||||
When we write our code using objects to represent entities, that's called an [object-oriented programming](https://en.wikipedia.org/wiki/Object-oriented_programming), in short: "OOP".
|
When we write our code using objects to represent entities, that's called an [object-oriented programming](https://en.wikipedia.org/wiki/Object-oriented_programming), in short: "OOP".
|
||||||
|
|
||||||
OOP is a big thing, an interesting science of its own. How to choose the right entities? How to organize the interaction between them? That's architecture, and there are great books on that topic, like "Design Patterns: Elements of Reusable Object-Oriented Software" by E.Gamma, R.Helm, R.Johnson, J.Vissides or "Object-Oriented Analysis and Design with Applications" by G.Booch, and more.
|
OOP is a big thing, an interesting science of its own. How to choose the right entities? How to organize the interaction between them? That's architecture, and there are great books on that topic, like "Design Patterns: Elements of Reusable Object-Oriented Software" by E.Gamma, R.Helm, R.Johnson, J.Vissides or "Object-Oriented Analysis and Design with Applications" by G.Booch, and more.
|
||||||
```
|
```
|
||||||
### Method shorthand
|
### Method shorthand
|
||||||
|
|
||||||
|
@ -72,14 +72,14 @@ There exists a shorter syntax for methods in an object literal:
|
||||||
```js
|
```js
|
||||||
// these objects do the same
|
// these objects do the same
|
||||||
|
|
||||||
let user = {
|
user = {
|
||||||
sayHi: function() {
|
sayHi: function() {
|
||||||
alert("Hello");
|
alert("Hello");
|
||||||
}
|
}
|
||||||
};
|
};
|
||||||
|
|
||||||
// method shorthand looks better, right?
|
// method shorthand looks better, right?
|
||||||
let user = {
|
user = {
|
||||||
*!*
|
*!*
|
||||||
sayHi() { // same as "sayHi: function()"
|
sayHi() { // same as "sayHi: function()"
|
||||||
*/!*
|
*/!*
|
||||||
|
|
|
@ -6,7 +6,9 @@ for (let li of document.querySelectorAll('li')) {
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
In the loop we need to get the text inside every `li`. We can read it directly from the first child node, that is the text node:
|
In the loop we need to get the text inside every `li`.
|
||||||
|
|
||||||
|
We can read the text from the first child node of `li`, that is the text node:
|
||||||
|
|
||||||
```js
|
```js
|
||||||
for (let li of document.querySelectorAll('li')) {
|
for (let li of document.querySelectorAll('li')) {
|
||||||
|
@ -16,4 +18,4 @@ for (let li of document.querySelectorAll('li')) {
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
Then we can get the number of descendants `li.getElementsByTagName('li')`.
|
Then we can get the number of descendants as `li.getElementsByTagName('li').length`.
|
||||||
|
|
|
@ -27,7 +27,7 @@ Also, there's a reference to the constructor function inside the `prototype`:
|
||||||
alert(HTMLDocument.prototype.constructor === HTMLDocument); // true
|
alert(HTMLDocument.prototype.constructor === HTMLDocument); // true
|
||||||
```
|
```
|
||||||
|
|
||||||
For built-in classes in all prototypes there's a `constructor` reference, and we can get `constructor.name` to see the name of the class. Let's do it for all objects in the `document` prototype chain:
|
To get a name of the class as a string, we can use `constructor.name`. Let's do it for the whole `document` prototype chain, till class `Node`:
|
||||||
|
|
||||||
```js run
|
```js run
|
||||||
alert(HTMLDocument.prototype.constructor.name); // HTMLDocument
|
alert(HTMLDocument.prototype.constructor.name); // HTMLDocument
|
||||||
|
|
|
@ -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`. In the browser there may be not only HTML, but also XML and SVG documents. 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 various 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 various 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,
|
||||||
|
@ -76,7 +76,7 @@ Try it on `document.body`.
|
||||||
```
|
```
|
||||||
|
|
||||||
````smart header="IDL in the spec"
|
````smart header="IDL in the spec"
|
||||||
In the specification, classes are described not using JavaScript, but a special [Interface description language](https://en.wikipedia.org/wiki/Interface_description_language) (IDL), that is usually easy to understand.
|
In the specification, DOM classes are described not using JavaScript, but a special [Interface description language](https://en.wikipedia.org/wiki/Interface_description_language) (IDL), that is usually easy to understand.
|
||||||
|
|
||||||
In IDL all properties are prepended with their types. For instance, `DOMString`, `boolean` and so on.
|
In IDL all properties are prepended with their types. For instance, `DOMString`, `boolean` and so on.
|
||||||
|
|
||||||
|
@ -156,7 +156,7 @@ alert( document.body.nodeName ); // BODY
|
||||||
alert( document.body.tagName ); // BODY
|
alert( document.body.tagName ); // BODY
|
||||||
```
|
```
|
||||||
|
|
||||||
Is there any difference between tagName and nodeName?
|
Is there any difference between `tagName` and `nodeName`?
|
||||||
|
|
||||||
Sure, the difference is reflected in their names, but is indeed a bit subtle.
|
Sure, the difference is reflected in their names, but is indeed a bit subtle.
|
||||||
|
|
||||||
|
@ -175,11 +175,11 @@ For instance, let's compare `tagName` and `nodeName` for the `document` and a co
|
||||||
|
|
||||||
<script>
|
<script>
|
||||||
// for comment
|
// for comment
|
||||||
alert( document.body.firstChild.tagName ); // undefined (no element)
|
alert( document.body.firstChild.tagName ); // undefined (not an element)
|
||||||
alert( document.body.firstChild.nodeName ); // #comment
|
alert( document.body.firstChild.nodeName ); // #comment
|
||||||
|
|
||||||
// for document
|
// for document
|
||||||
alert( document.tagName ); // undefined (not element)
|
alert( document.tagName ); // undefined (not an element)
|
||||||
alert( document.nodeName ); // #document
|
alert( document.nodeName ); // #document
|
||||||
</script>
|
</script>
|
||||||
</body>
|
</body>
|
||||||
|
@ -232,14 +232,12 @@ We can try to insert invalid HTML, the browser will fix our errors:
|
||||||
```
|
```
|
||||||
|
|
||||||
```smart header="Scripts don't execute"
|
```smart header="Scripts don't execute"
|
||||||
If `innerHTML` inserts a `<script>` tag into the document -- it doesn't execute.
|
If `innerHTML` inserts a `<script>` tag into the document -- it becomes a part of HTML, but doesn't execute.
|
||||||
|
|
||||||
It becomes a part of HTML, just as a script that has already run.
|
|
||||||
```
|
```
|
||||||
|
|
||||||
### Beware: "innerHTML+=" does a full overwrite
|
### Beware: "innerHTML+=" does a full overwrite
|
||||||
|
|
||||||
We can append "more HTML" by using `elem.innerHTML+="something"`.
|
We can append HTML to an element by using `elem.innerHTML+="more html"`.
|
||||||
|
|
||||||
Like this:
|
Like this:
|
||||||
|
|
||||||
|
@ -327,7 +325,7 @@ The `innerHTML` property is only valid for element nodes.
|
||||||
|
|
||||||
Other node types have their counterpart: `nodeValue` and `data` properties. These two are almost the same for practical use, there are only minor specification differences. So we'll use `data`, because it's shorter.
|
Other node types have their counterpart: `nodeValue` and `data` properties. These two are almost the same for practical use, there are only minor specification differences. So we'll use `data`, because it's shorter.
|
||||||
|
|
||||||
We can read it, like this:
|
An example of reading the content of a text node and a comment:
|
||||||
|
|
||||||
```html run height="50"
|
```html run height="50"
|
||||||
<body>
|
<body>
|
||||||
|
@ -347,7 +345,7 @@ We can read it, like this:
|
||||||
</body>
|
</body>
|
||||||
```
|
```
|
||||||
|
|
||||||
For text nodes we can imagine a reason to read or modify them, but why comments? Usually, they are not interesting at all, but sometimes developers embed information into HTML in them, like this:
|
For text nodes we can imagine a reason to read or modify them, but why comments? Usually, they are not interesting at all, but sometimes developers embed information or template instructions into HTML in them, like this:
|
||||||
|
|
||||||
```html
|
```html
|
||||||
<!-- if isAdmin -->
|
<!-- if isAdmin -->
|
||||||
|
@ -470,7 +468,7 @@ Each DOM node belongs to a certain class. The classes form a hierarchy. The full
|
||||||
Main DOM node properties are:
|
Main DOM node properties are:
|
||||||
|
|
||||||
`nodeType`
|
`nodeType`
|
||||||
: We can get `nodeType` from the DOM object class, but often we need just to see if it is a text or element node. The `nodeType` property is good for that. It has numeric values, most important are: `1` -- for elements,`3` -- for text nodes. Read-only.
|
: We can use it to see if a node is a text or an element node. It has a numeric value: `1` -- for elements,`3` -- for text nodes, and few other for other node types. Read-only.
|
||||||
|
|
||||||
`nodeName/tagName`
|
`nodeName/tagName`
|
||||||
: For elements, tag name (uppercased unless XML-mode). For non-element nodes `nodeName` describes what it is. Read-only.
|
: For elements, tag name (uppercased unless XML-mode). For non-element nodes `nodeName` describes what it is. Read-only.
|
||||||
|
@ -485,11 +483,11 @@ Main DOM node properties are:
|
||||||
: The content of a non-element node (text, comment). These two are almost the same, usually we use `data`. Can be modified.
|
: The content of a non-element node (text, comment). These two are almost the same, usually we use `data`. Can be modified.
|
||||||
|
|
||||||
`textContent`
|
`textContent`
|
||||||
: The text inside the element, basically HTML minus all `<tags>`. Writing into it puts the text inside the element, with all special characters and tags treated exactly as text. Can safely insert user-generated text and protect from unwanted HTML insertions.
|
: The text inside the element: HTML minus all `<tags>`. Writing into it puts the text inside the element, with all special characters and tags treated exactly as text. Can safely insert user-generated text and protect from unwanted HTML insertions.
|
||||||
|
|
||||||
`hidden`
|
`hidden`
|
||||||
: When set to `true`, does the same as CSS `display:none`.
|
: When set to `true`, does the same as CSS `display:none`.
|
||||||
|
|
||||||
DOM nodes also have other properties depending on their class. For instance, `<input>` elements (`HTMLInputElement`) support `value`, `type`, while `<a>` elements (`HTMLAnchorElement`) support `href` etc. Most standard HTML attributes have a corresponding DOM property.
|
DOM nodes also have other properties depending on their class. For instance, `<input>` elements (`HTMLInputElement`) support `value`, `type`, while `<a>` elements (`HTMLAnchorElement`) support `href` etc. Most standard HTML attributes have a corresponding DOM property.
|
||||||
|
|
||||||
But HTML attributes and DOM properties are not always the same, as we'll see in the next chapter.
|
Although, HTML attributes and DOM properties are not always the same, as we'll see in the next chapter.
|
||||||
|
|
|
@ -151,9 +151,7 @@ There are two possible values of the `capture` option:
|
||||||
|
|
||||||
Note that while formally there are 3 phases, the 2nd phase ("target phase": the event reached the element) is not handled separately: handlers on both capturing and bubbling phases trigger at that phase.
|
Note that while formally there are 3 phases, the 2nd phase ("target phase": the event reached the element) is not handled separately: handlers on both capturing and bubbling phases trigger at that phase.
|
||||||
|
|
||||||
If one puts capturing and bubbling handlers on the target element, the capture handler triggers last in the capturing phase and the bubble handler triggers first in the bubbling phase.
|
Let's see both capturing and bubbling in action:
|
||||||
|
|
||||||
Let's see it in action:
|
|
||||||
|
|
||||||
```html run autorun height=140 edit
|
```html run autorun height=140 edit
|
||||||
<style>
|
<style>
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue