minor

iliakan · iliakan · commit 902a7e7f6e4d · 2019-08-05T01:39:21.000+03:00
diff --git a/2-ui/1-document/05-basic-dom-node-properties/4-where-document-in-hierarchy/solution.md b/2-ui/1-document/05-basic-dom-node-properties/4-where-document-in-hierarchy/solution.md
@@ -35,4 +35,6 @@ alert(HTMLDocument.prototype.__proto__.constructor.name); // Document
 alert(HTMLDocument.prototype.__proto__.__proto__.constructor.name); // Node
 ```
 
+That's the hierarchy.
+
 We also could examine the object using `console.dir(document)` and see these names by opening `__proto__`. The console takes them from `constructor` internally.
diff --git a/2-ui/1-document/05-basic-dom-node-properties/article.md b/2-ui/1-document/05-basic-dom-node-properties/article.md
@@ -2,11 +2,11 @@
 
 Let's get a more in-depth look at DOM nodes.
 
-In this chapter we'll see more into what they are and their most used properties.
+In this chapter we'll see more into what they are and learn their most used properties.
 
 ## DOM node classes
 
-DOM nodes have different properties depending on their class. For instance, an element node corresponding to tag `<a>` has link-related properties, and the one corresponding to `<input>` has input-related properties and so on. Text nodes are not the same as element nodes. But there are also common properties and methods between all of them, because all classes of DOM nodes form a single hierarchy.
+Different DOM nodes may have different properties. For instance, an element node corresponding to tag `<a>` has link-related properties, and the one corresponding to `<input>` has input-related properties and so on. Text nodes are not the same as element nodes. But there are also common properties and methods between all of them, because all classes of DOM nodes form a single hierarchy.
 
 Each DOM node belongs to the corresponding built-in class.
 
@@ -21,22 +21,24 @@ 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.
 - [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`.
-- [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 concrete HTML 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,
-    - [HTMLAnchorElement](https://html.spec.whatwg.org/multipage/semantics.html#htmlanchorelement) -- the class for `<a>` elements
+    - [HTMLAnchorElement](https://html.spec.whatwg.org/multipage/semantics.html#htmlanchorelement) -- the class for `<a>` elements,
     - ...and so on, each tag has its own class that may provide specific properties and methods.
 
 So, the full set of properties and methods of a given node comes as the result of the inheritance.
 
-For example, let's consider the DOM object for an `<input>` element. It belongs to [HTMLInputElement](https://html.spec.whatwg.org/multipage/forms.html#htmlinputelement) class. It gets properties and methods as a superposition of:
+For example, let's consider the DOM object for an `<input>` element. It belongs to [HTMLInputElement](https://html.spec.whatwg.org/multipage/forms.html#htmlinputelement) class.
 
-- `HTMLInputElement` -- this class provides input-specific properties, and inherits from...
-- `HTMLElement` -- it provides common HTML element methods (and getters/setters) and inherits from...
-- `Element` -- provides generic element methods and inherits from...
-- `Node` -- provides common DOM node properties and inherits from...
+It gets properties and methods as a superposition of (listed in inheritance order):
+
+- `HTMLInputElement` -- this class provides input-specific properties,
+- `HTMLElement` -- it provides common HTML element methods (and getters/setters),
+- `Element` -- provides generic element methods,
+- `Node` -- provides common DOM node properties,.
 - `EventTarget` -- gives the support for events (to be covered),
-- ...and finally it inherits from `Object`, so "pure object" methods like `hasOwnProperty` are also available.
+- ...and finally it inherits from `Object`, so "plain object" methods like `hasOwnProperty` are also available.
 
 To see the DOM node class name, we can recall that an object usually has the `constructor` property. It references the class constructor, and `constructor.name` is its name:
 
@@ -91,7 +93,7 @@ interface HTMLInputElement: HTMLElement {
   // here go properties and methods of <input> elements
 
 *!*
-  // "DOMString" means that the value of these properties are strings
+  // "DOMString" means that the value of a property is a string
 */!*
   attribute DOMString accept;
   attribute DOMString alt;
@@ -110,13 +112,11 @@ interface HTMLInputElement: HTMLElement {
   ...
 }
 ```
-
-Other classes are somewhat similar.
 ````
 
 ## The "nodeType" property
 
-The `nodeType` property provides an old-fashioned way to get the "type" of a DOM node.
+The `nodeType` property provides one more, "old-fashioned" way to get the "type" of a DOM node.
 
 It has a numeric value:
 - `elem.nodeType == 1` for element nodes,
@@ -185,8 +185,7 @@ For instance, let's compare `tagName` and `nodeName` for the `document` and a co
 </body>
 ```
 
-If we only deal with elements, then `tagName` is the only thing we should use.
-
+If we only deal with elements, then we can use both `tagName` and `nodeName` - there's no difference.
 
 ```smart header="The tag name is always uppercase except XHTML"
 The browser has two modes of processing documents: HTML and XML. Usually the HTML-mode is used for webpages. XML-mode is enabled when the browser receives an XML-document with the header: `Content-Type: application/xml+xhtml`.
@@ -300,30 +299,35 @@ Consider the example:
 *!*
   // replace div.outerHTML with <p>...</p>
 */!*
-  div.outerHTML = '<p>A new element!</p>'; // (*)
+  div.outerHTML = '<p>A new element</p>'; // (*)
 
 *!*
   // Wow! The div is still the same!
 */!*
-  alert(div.outerHTML); // <div>Hello, world!</div>
+  alert(div.outerHTML); // <div>Hello, world!</div> (**)
 </script>
 ```
 
-In the line `(*)` we take the full HTML of `<div>...</div>` and replace it by `<p>...</p>`. In the outer document we can see the new content instead of the `<div>`. But the old `div` variable is still the same.
+Looks really odd, right?
 
-The `outerHTML` assignment does not modify the DOM element, but extracts it from the outer context and inserts a new piece of HTML instead of it.
+In the line `(*)` we replaced `div` with `<p>A new element</p>`. In the outer document we can see the new content instead of the `<div>`. But, as we can see in line `(**)`, the old `div` variable is still the same!
 
-Novice developers sometimes make an error here: they modify `div.outerHTML` and then continue to work with `div` as if it had the new content in it.
+The `outerHTML` assignment does not modify the DOM element, but removes it from the outer context and inserts a new piece of HTML instead of it.
 
-That's possible with `innerHTML`, but not with `outerHTML`.
+So what happened in `div.outerHTML=...` is:
+- `div` was removed from the document.
+- Another HTML `<p>A new element</p>` was inserted instead.
+- `div` still has the old value. The new HTML wasn't saved to any variable.
 
-We can write to `outerHTML`, but should keep in mind that it doesn't change the element we're writing to. It creates the new content on its place instead. We can get a reference to new elements by querying DOM.
+It's so easy to make an error here: modify `div.outerHTML` and then continue to work with `div` as if it had the new content in it. But it doesn't. Such thing is correct for `innerHTML`, but not for `outerHTML`.
+
+We can write to `elem.outerHTML`, but should keep in mind that it doesn't change the element we're writing to. It creates the new HTML on its place instead. We can get references to new elements by querying DOM.
 
 ## nodeValue/data: text node content
 
 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, such as text nodes, 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.
 
 An example of reading the content of a text node and a comment:
 
@@ -345,15 +349,17 @@ An example of reading the content of a text node and a comment:
 </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 or template instructions into HTML in them, like this:
+For text nodes we can imagine a reason to read or modify them, but why comments?
+
+Sometimes developers embed information or template instructions into HTML in them, like this:
 
 ```html
 <!-- if isAdmin -->
   <div>Welcome, Admin!</div>
 <!-- /if -->
 ```
 
-...Then JavaScript can read it and process embedded instructions.
+...Then JavaScript can read it from `data` property and process embedded instructions.
 
 ## textContent: pure text
 
@@ -436,7 +442,7 @@ Here's a blinking element:
 
 ## More properties
 
-DOM elements also have additional properties, many of them provided by the class:
+DOM elements also have additional properties, in particular those that depend on the class:
 
 - `value` -- the value for `<input>`, `<select>` and `<textarea>` (`HTMLInputElement`, `HTMLSelectElement`...).
 - `href` -- the "href" for `<a href="...">` (`HTMLAnchorElement`).
@@ -457,7 +463,7 @@ For instance:
 
 Most standard HTML attributes have the corresponding DOM property, and we can access it like that.
 
-If we want to know the full list of supported properties for a given class, we can find them in the specification. For instance, HTMLInputElement is documented at <https://html.spec.whatwg.org/#htmlinputelement>.
+If we want to know the full list of supported properties for a given class, we can find them in the specification. For instance, `HTMLInputElement` is documented at <https://html.spec.whatwg.org/#htmlinputelement>.
 
 Or if we'd like to get them fast or are interested in a concrete browser specification -- we can always output the element using `console.dir(elem)` and read the properties. Or explore "DOM properties" in the Elements tab of the browser developer tools.
 
