@webqit/oohtml 2.1.77 → 2.1.79

package/README.md

@@ -71,22 +71,6 @@ let { user } = document.namespace;
 let { url, name, email } = user.namespace;
 ```
 
-<details><summary>Learn more</summary>
-
-You want to see how IDs are otherwise exposed as global variables:
-
-```html
-<div id="foo"><div>
-```
-
-```js
-console.log(window.foo); // div
-```
-
-[Read more](https://stackoverflow.com/questions/6381425/is-there-a-spec-that-the-id-of-elements-should-be-made-global-variable)
-
-</details>
-
 <details><summary>All in Realtime</summary>
 
 The Namespace API is designed to always reflect the DOM in real-time. This may be observed using the general-purpose object observability API - [Observer API](https://github.com/webqit/observer):
@@ -118,6 +102,22 @@ function changeCallback(changes) {
 
 </details>
 
+<details><summary>Learn more</summary>
+
+You want to see how IDs are otherwise exposed as global variables:
+
+```html
+<div id="foo"><div>
+```
+
+```js
+console.log(window.foo); // div
+```
+
+[Read more](https://stackoverflow.com/questions/6381425/is-there-a-spec-that-the-id-of-elements-should-be-made-global-variable)
+
+</details>
+
 ### Scoping
 
 We often need a way to keep things like styles and scripts [scoped to a component](https://vuejs.org/guide/scaling-up/sfc.html).
@@ -144,8 +144,6 @@ Here, we get the `scoped` attribute for *scoping* said element-specific styleshe
 let { styleSheets, scripts } = user; // APIs that are analogous to the document.styleSheets, document.scripts properties
 ```
 
-└ [Modular HTML examples](#modular-html-examples)
-
 ## HTML Imports
 
 HTML Imports is a realtime module system for HTML written in HTML! Something like it is the [`<defs>`](https://developer.mozilla.org/en-US/docs/Web/SVG/Element/defs) and [`<use>`](https://developer.mozilla.org/en-US/docs/Web/SVG/Element/use) system in SVG.
@@ -154,7 +152,7 @@ OOHTML makes this possible in just simple conventions - via a new `def` attribut
 
 ### Module Definition
 
-A module here is any piece of markup that will be reused.
+A module here is any piece of markup that can be reused.
 
 Here, we get the `def` attribute for defining those - either as whole *module* or as *fragment*:
 
@@ -239,9 +237,9 @@ Here, we get an `<import>` element that lets us do that declaratively:
 
 <details><summary>All in Realtime</summary>
 
-As a realtime module system, `<import> `elements maintain a live relationship with given module definition `<template def>` elements and are resolved again in the event that:
+As a realtime module system, `<import> `elements maintain a live relationship with given module definition elements (`<template def>`) and are resolved again in the event that:
 + the `<import>` element points to another module — either by `ref` change or by a change in `importscontext` (below).
-+ the module definition `<template def>` element has had its contents updated, either programmatically or automatically from having loaded.
++ the module definition element (`<template def>`) has had its contents updated, either programmatically or automatically from having loaded.
 
 Conversely, an `<import>` element that has been resolved will self-restore in the event that:
 + the `<import>` element no longer points to a module; or the module has been emptied or removed.
@@ -264,7 +262,7 @@ The above resolved imports would thus give us something like:
 </body>
 ```
 
-But they also have to remember the exact imported nodes that they manage so as to be able to re-establish that relationship on getting to the client. This information is automatically encoded as part of the serialised element itself, in something like:
+But they also would need to remember the exact imported nodes that they manage so as to be able to re-establish that relationship on getting to the client. This information is automatically encoded as part of the serialised element itself, in something like:
 
 ```html
 <!--&lt;import ref="/foo/nested#fragment2" nodecount="1"&gt;&lt;/import&gt;-->
@@ -364,7 +362,7 @@ setTimeout(() => abortController.abort(), 1000);
 
 We can defer module loading until we really need them.
 
-Here, we get the `loading="lazy"` directive for that:
+Here, we get the `loading="lazy"` directive for that; and loading is only then triggered on the first attempt to import its contents:
 
 ```html
 <!-- Loading doesn't happen until the first time this is being accessed -->
@@ -382,7 +380,7 @@ const moduleObject2 = document.import('/foo#fragment1'); // Triggers module load
 
 ### Scoped Modules
 
-Some modules will only be relevant within a specific context in the page.
+Some modules will only be relevant within a specific context in the page, and these shouldn't map to the global document scope.
 
 Here, we get the `scoped` attribute for scoping those to their respective contexts, and thus, implicitly have an *object-scoped* module system:
 
@@ -566,8 +564,6 @@ console.log(localOrGlobalImport2); // { value: div }
 
 </details>
 
-└ [HTML Imports examples](#html-imports-examples)
-
 ## Data Binding
 
 Data binding is the concept of having a mechanism that declaratively drives the UI from application data, ensuring that the relevant parts of the UI are *automatically* updated as application state changes.
@@ -576,7 +572,7 @@ OOHTML makes this possible in just simple conventions - via a new comment-based
 
 ### Discrete Data-Binding
 
-Here, we get a comment-based data-binding syntax `<?{ }?>` which works like regular comment but stay "data-charged":
+Here, we get a comment-based data-binding tag `<?{ }?>` which works like regular comment but stay "data-charged":
 
 ```js
 <html>
@@ -596,7 +592,7 @@ On the server, these data-binding tags would retain their place in the DOM while
 
 The following: `<?{ 'Hello World' }?>` would thus give us: `<?{ 'Hello World' }?>Hello World`.
 
-But they also have to remember the exact text node that they manage, so as to be able to re-establish that relationship on getting to the client. That information is automatically encoded as part of the declaration itself, and that brings us to having a typical server-rendered binding look like this:
+But they also would need to remember the exact text node that they manage, so as to be able to re-establish that relationship on getting to the client. That information is automatically encoded as part of the declaration itself, and that brings us to having a typical server-rendered binding look like this:
 
 ```html
 <?{ 'Hello World'; [=11] }?>Hello World

package/package.json

@@ -14,7 +14,7 @@
     "wicg-proposal"
   ],
   "homepage": "https://webqit.io/tooling/oohtml",
-  "version": "2.1.77",
+  "version": "2.1.79",
   "license": "MIT",
   "repository": {
     "type": "git",