npm - @webqit/oohtml - Versions diffs - 3.0.1-9 → 3.1.2 - Mend

@webqit/oohtml 3.0.1-9 → 3.1.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (50) hide show

package/README.md +532 -229
package/dist/bindings-api.js +1 -1
package/dist/bindings-api.js.map +3 -3
package/dist/context-api.js +1 -1
package/dist/context-api.js.map +3 -3
package/dist/data-binding.js +16 -36
package/dist/data-binding.js.map +3 -3
package/dist/html-imports.js +1 -1
package/dist/html-imports.js.map +3 -3
package/dist/main.js +31 -37
package/dist/main.js.map +3 -3
package/dist/main.lite.js +56 -0
package/dist/main.lite.js.map +7 -0
package/dist/namespaced-html.js +1 -1
package/dist/namespaced-html.js.map +3 -3
package/dist/scoped-css.js +3 -3
package/dist/scoped-css.js.map +2 -2
package/dist/scoped-js.js +1 -21
package/dist/scoped-js.js.map +3 -3
package/package.json +3 -5
package/src/api.global.js +11 -0
package/src/api.global.lite.js +11 -0
package/src/bindings-api/DOMBindingsContext.js +51 -0
package/src/bindings-api/index.js +30 -42
package/src/context-api/DOMContext.js +128 -0
package/src/context-api/DOMContextResponse.js +15 -0
package/src/context-api/DOMContexts.js +89 -0
package/src/context-api/DuplicateContextError.js +2 -0
package/src/context-api/_DOMContextRequestEvent.js +49 -0
package/src/context-api/index.js +20 -22
package/src/data-binding/index.js +20 -26
package/src/html-imports/{_HTMLImportsProvider.js → HTMLImportsContext.js} +42 -33
package/src/html-imports/{_HTMLExportsManager.js → HTMLModule.js} +40 -38
package/src/html-imports/_HTMLImportElement.js +17 -17
package/src/html-imports/index.js +46 -49
package/src/index.js +2 -7
package/src/namespaced-html/index.js +3 -7
package/src/scoped-css/index.js +1 -1
package/src/scoped-js/index.js +2 -13
package/src/util.js +8 -5
package/test/imports.test.js +1 -3
package/test/index.js +1 -1
package/test/modules.test.js +35 -38
package/src/bindings-api/_HTMLBindingsProvider.js +0 -51
package/src/context-api/ContextReturnValue.js +0 -22
package/src/context-api/HTMLContext.js +0 -85
package/src/context-api/HTMLContextProvider.js +0 -175
package/src/context-api/_ContextRequestEvent.js +0 -26
package/src/html-imports/_HTMLImportElement copy.js +0 -217
package/src/targets.browser.js +0 -10

package/README.md CHANGED Viewed

@@ -25,7 +25,9 @@ Vanilla HTML is unsurprisingly becoming a compelling option for an increasing nu
 This project pursues an object-oriented approach to HTML and implicitly revisits much of what inhibits the idea of a *component* architecture for HTML!
+<!--
 └ [See more in the introductory blog post](https://dev.to/oxharris/the-web-native-equations-1m1p-temp-slug-6661657?preview=ba70ad2c17f05b5761bc74516dbde8c9eff8b581a0420d87334fd9ef6bab9d6e6d3ab6aaf3fe02542bb9e7250d0a88a6df91dae40919aabcc9a07320)<sup>draft</sup>
+-->
 </details>
@@ -66,7 +68,7 @@ user
  └── email
 ```
-**-->** *with a corresponding API that exposes said structure to JavaScript applications*:
+**-->** *with a complementary API that exposes said structure to JavaScript applications*:
 ```js
 // The document.namespace API
@@ -142,7 +144,7 @@ Here, we get the `scoped` attribute for *scoping* said element-specific styleshe
 </div>
 ```
-**-->** *with a corresponding API that exposes said assets to JavaScript applications*:
+**-->** *with a complementary API that exposes said assets to JavaScript applications*:
 ```js
 let { styleSheets, scripts } = user; // APIs that are analogous to the document.styleSheets, document.scripts properties
@@ -201,7 +203,7 @@ Here, we get the `def` attribute for defining those - either as whole *module* o
 We shouldn't need a different mechanism to work with remote content.
-Here, we get the `<template src>` element for that:
+Here, we get remote-loading modules using the `src` attribute:
 ```html
 <template def="foo" src="/foo.html"></template>
@@ -218,10 +220,9 @@ Here, we get the `<template src>` element for that:
 ```html
 -- file: /nested.html --
 <div def="fragment2"></div>
---
 ```
-**-->** *which extends how elements like images already work; terminating with either a `load` or an `error` event*:
+**-->** *which borrow from how `src` works in elements like `<img>`; terminating with either a `load` or an `error` event*:
 ```js
 foo.addEventListener('load', loadCallback);
@@ -230,9 +231,9 @@ foo.addEventListener('error', errorCallback);
 ### Declarative Module Imports
-The essence of a module is for reuse.
+HTML snippets should be reusable in "HTML"!
-Here, we get an `<import>` element that lets us do that declaratively:
+Here, we get an `<import>` element that lets us do just that:
 ```html
 <body>
@@ -250,19 +251,21 @@ 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 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 element (`<template def>`) has had its contents updated, either programmatically or automatically from having loaded.
+Import *refs* are live bindings that are highly sensitive to:
++ changes in the *ref* itself (in being defined/undefined/redefined)
++ changes in the referenced *defs* themselves (in being added/removed/loaded)
+And an `<import>` element that has been resolved will self-restore in the event that:
-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.
-+ the previously slotted contents have been programmatically removed and slot is empty.
++ the above changes resolve to no imports.
++ the previously slotted contents have *all* been programmatically removed and slot is empty.
 </details>
-<details><summary>With SSR Support</summary>
+<details><summary>With SSR support</summary>
-On the server, these `<import>` elements would retain their place in the DOM, but this time, serialized into comment nodes, while having their output rendered just above them as siblings.
+On the server, these `<import>` elements will retain their place in the DOM, but this time, serialized into comment nodes, while having their output rendered just above them as siblings.
 The above resolved imports would thus give us something like:
@@ -275,23 +278,23 @@ The above resolved imports would thus give us something like:
 </body>
 ```
-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:
+But they also will need to remember the exact imported nodes that they manage so as to be able to re-establish relevant relationships 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;-->
 ```
-Now that extra bit of information gets decoded and original relationships are formed again on getting to the client and "hydrating" the `<import>` element. But, the `<import>` element itself stays invisible in the DOM while still continuing to kick as above!
+Now, on getting to the client and getting "hydrated" back into an `<import>` element, that extra bit of information is decoded, and original relationships are formed again. But, the `<import>` element itself stays invisible in the DOM while still continuing to kick as above!
 > Note: We know we're on the server when `window.webqit.env === 'server'`. This flag is automatically set by OOHTML's current SSR engine: [OOHTML-SSR](https://github.com/webqit/oohtml-ssr)
 </details>
-### Programmatic Module Imports
+### Imperative Module Imports
 JavaScript applications will need more than a declarative import mechanism.
-Here, we get an *HTMLImports* API for programmatic module import:
+Here, we get an *HTMLImports* API for imperative module import:
 ```js
 const moduleObject1 = document.import('/foo#fragment1');
@@ -303,7 +306,7 @@ const moduleObject2 = document.import('/foo/nested#fragment2');
 console.log(moduleObject2.value); // divElement
 ```
-**-->** *with an observable `moduleObject.value` property for working asynchronously; e.g. awaiting and handling remote modules*:
+**-->** *with the `moduleObject.value` property being a live property for when results are delivered asynchronous; e.g. with an asynchronously loaded module*:
 ```js
 Observer.observe(moduleObject2, 'value', e => {
@@ -319,7 +322,7 @@ document.import('/foo#fragment1', divElement => {
 });
 ```
-**-->** *with an optional `live` parameter for staying subscribed to any mutations made to source module elements*:
+**-->** *with an optional `live` parameter for staying subscribed to updated results*:
 ```js
 const moduleObject2 = document.import('/foo/nested#fragment2', true/*live*/);
@@ -335,38 +338,25 @@ document.import('/foo#fragment1', true/*live*/, divElement => {
 });
 ```
-*...both of which would get notified on doing the below*:
+*...both of which get notified on doing the below*:
 ```js
 document.querySelector('template[def="foo"]').content.firstElementChild.remove();
 ```
-**-->** *with an optional `AbortSignal` parameter for aborting module mutation events*:
+**-->** *with a `moduleObject.abort()` method for unsubscribing from live updates*:
-```js
-const abortController = new AbortController;
-```
+**-->** *with an optional `signal` parameter for passing in a custom `AbortSignal` instance*:
 ```js
+const abortController = new AbortController;
 const moduleObject2 = document.import('/foo/nested#fragment2', { live: true, signal: abortController.signal });
 ```
-*...in the absence of which an `AbortSignal` instance is automatically created internally for the same purpose, such that we're always able to do*:
-```js
-moduleObject2.abort();
-```
-*...whereas in the `callback` approach, no automatic `AbortSignals` are created*:
 ```js
-document.import('/foo#fragment1', { live: true, signal: abortController.signal }, divElement => {
-    console.log(divElement); // To be received after remote module has been loaded
-});
-```
-```js
-setTimeout(() => abortController.abort(), 1000);
+setTimeout(() => {
+  abortController.abort(); // which would also call moduleObject2.abort()
+}, 1000);
 ```
 <details><summary>Extended Imports concepts</summary>
@@ -375,7 +365,7 @@ setTimeout(() => abortController.abort(), 1000);
 We can defer module loading until we really need them.
-Here, we get the `loading="lazy"` directive for that; and loading is only then triggered on the first attempt to import their contents:
+Here, we get the `loading="lazy"` directive for that; and loading is only then triggered on the first attempt to import them or their contents:
 ```html
 <!-- Loading doesn't happen until the first time this is being accessed -->
@@ -391,43 +381,6 @@ Here, we get the `loading="lazy"` directive for that; and loading is only then t
 const moduleObject2 = document.import('/foo#fragment1'); // Triggers module loading and resolves at moduleObject2.value on load success
 ```
-### Scoped Modules
-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:
-```html
-<section> <!-- object with own modules -->
-  <template def="foo" scoped> <!-- Scoped to host object and not available globally -->
-    <div def="fragment1"></div>
-  </template>
-  <div>
-    <import ref="foo#fragment1"></import> <!-- Relative path (beginning without a slash), resolves to the local module: foo#fragment1 -->
-    <import ref="/foo#fragment1"></import> <!-- Absolute path, resolves to the global module: /foo#fragment1 -->
-  </div>
-</section>
-```
-**-->** *with an equivalent `Element.prototype.import()` API for accessing said scoped modules*:
-```js
-// Using the HTMLImports API
-const moduleHost = document.querySelector('div');
-const localImport1 = moduleHost.import('foo#fragment1'); // the local module: foo#fragment1
-console.log(localImport1); // { value: div }
-```
-```js
-// Using the HTMLImports API
-const moduleHost = document.querySelector('div');
-const globalImport1 = moduleHost.import('/foo#fragment1'); // the global module: foo#fragment1
-console.log(globalImport1); // { value: div }
-```
 ### Module Inheritance
 We'll often have repeating markup structures.
@@ -478,80 +431,142 @@ Here, we get module nesting with inheritance to simplify that:
 ### Imports Contexts
-We should be able to define a base path at arbitrary levels in the page against which to resolve import *refs* in subtree.
+We should be able to have *relative* import refs that resolve against local contexts in the document tree.
+Here, we call those arbitrary contexts "Imports Contexts", and these could be:
++ Simple Base Path Contexts ([below](#base-path-contexts))
++ Scoped Module Contexts ([below](#scoped-module-contexts))
++ Named Contexts ([below](#named-contexts))
++ Extended Scoped Module Contexts ([below](#extended-scoped-module-contexts))
+Alongside which we have a complementary `Element.prototype.import()` API for thinking in contexts.
+#### "Base Path" Contexts
-Here, we get "Imports Contexts" for that:
+Base paths may be defined at arbitrary levels in the page using the `importscontext` attribute:
 ```html
 <body importscontext="/foo">
   <section>
-    <import ref="#fragment1"></import> <!-- Relative path (beginning without a slash), resolves to: /foo#fragment1 -->
+    <import ref="#fragment1"></import> <!-- Relative path (beginning without a slash), resolving to: /foo#fragment1 -->
   </section>
 </body>
 ```
 ```html
 <body importscontext="/foo/nested">
+  <main>
+    <import ref="#fragment2"></import> <!-- Relative path (beginning without a slash), resolving to: /foo/nested#fragment2 -->
+  </main>
+</body>
+```
+**-->** *with said base paths being able to "nest" nicely*:
+```html
+<body importscontext="/foo">
   <section>
-    <import ref="#fragment2"></import> <!-- Relative path (beginning without a slash), resolves to: /foo/nested#fragment2 -->
+    <import ref="#fragment1"></import> <!-- Relative path (beginning without a slash), resolves to: /foo#fragment1 -->
   </section>
+  <div importscontext="nested"> <!-- Relative path (beginning without a slash), resolves to: /foo/nested -->
+    <main>
+      <import ref="#fragment2"></import> <!-- Relative path (beginning without a slash), resolves to: /foo/nested#fragment2 -->
+    </main>
+  </div>
 </body>
 ```
+**-->** *with the `Element.prototype.import()` API for equivalent context-based imports*:
 ```js
-// Using the HTMLImports API
-const moduleHost = document.querySelector('section');
-const globalImport2 = moduleHost.import('#fragment2'); // module:/foo/nested#fragment2
-console.log(globalImport2); // { value: div }
+// Using the HTMLImports API to import from context
+const contextElement = document.querySelector('section');
+const response = contextElement.import('#fragment1'); // Relative path (beginning without a slash), resolving to: /foo#fragment1
+```
+```js
+// Using the HTMLImports API to import from context
+const contextElement = document.querySelector('main');
+const response = contextElement.import('#fragment1'); // Relative path (beginning without a slash), resolving to: /foo/nested#fragment1
 ```
-**-->** *with said "Imports Contexts" optionally having a name*:
+#### "Scoped Module" Contexts
+Some modules will only be relevant within a specific context in the page, and those wouldn't need to have a business with the global scope.
+Here, we get the `scoped` attribute for scoping those to their respective contexts, to give us an *object-scoped* module system (like what Scoped Registries seek to be to Custom Elements):
 ```html
-<body contextname="context1" importscontext="/foo/nested">
+<section> <!-- Host object -->
-  <import ref="#fragment2"></import> <!-- Relative path (beginning without a slash), resolves to: /foo/nested#fragment2 -->
+  <template def="foo" scoped> <!-- Scoped to host object and not available globally -->
+    <div def="fragment1"></div>
+  </template>
-  <section importscontext="/foo">
-    <import ref="#fragment1"></import> <!-- Relative path (beginning without a slash), resolves to: /foo#fragment1 -->
-    <div>
-      <import ref="@context1#fragment2"></import> <!-- Context-relative path (beginning with a context name), resolves to: /foo/nested#fragment2 -->
-    </div>
-  </section>
+  <div>
+    <import ref="foo#fragment1"></import> <!-- Relative path (beginning without a slash), resolving to the local module: foo#fragment1 -->
+    <import ref="/foo#fragment1"></import> <!-- Absolute path, resolving to the global module: /foo#fragment1 -->
+  </div>
-</body>
+</section>
 ```
+**-->** *with the `Element.prototype.import()` API for equivalent context-based imports*:
 ```js
-// Using the HTMLImports API
-const moduleHost = document.querySelector('div');
-const globalImport2 = moduleHost.import('@context1#fragment2'); // module:/foo/nested#fragment2
-console.log(globalImport2); // { value: div }
+// Using the HTMLImports API for local import
+const contextElement = document.querySelector('div');
+const localModule = moduleHost.import('#fragment1'); // Relative path (beginning without a slash), resolving to the local module: foo#fragment1
 ```
-**-->** *with said "Imports Contexts" being able to "nest" nicely*:
+```js
+// Using the HTMLImports API for global import
+const contextElement = document.querySelector('div');
+const globalModule = contextElement.import('/foo#fragment1'); // Absolute path, resolving to the global module: /foo#fragment1
+```
+#### Named Contexts
+Imports Contexts may be named:
 ```html
-<body importscontext="/foo">
+<body contextname="context1" importscontext="/foo/nested">
-  <import ref="#fragment1"></import> <!-- Relative path (beginning without a slash), resolves to: /foo#fragment1 -->
+  <import ref="#fragment2"></import> <!-- Relative path (beginning without a slash), resolves to: /foo/nested#fragment2 -->
+  <section importscontext="/foo">
+    <import ref="#fragment1"></import> <!-- Relative path (beginning without a slash), resolves to: /foo#fragment1 -->
+    <div>
+      <import ref="@context1#fragment2"></import> <!-- Context-relative path (beginning with a context name), resolves to: /foo/nested#fragment2 -->
+    </div>
-  <section importscontext="nested"> <!-- Relative path (beginning without a slash), resolves to: /foo/nested -->
-    <import ref="#fragment2"></import> <!-- Relative path (beginning without a slash), resolves to: /foo/nested#fragment2 -->
   </section>
 </body>
 ```
-### Scoped Modules and Imports Contexts
+**-->** *with the `Element.prototype.import()` API for equivalent context-based imports*:
-Scoped modules and Import Contexts shouldn't be mutually exclusive.
+```js
+// Using the HTMLImports API to import from a named Imports Context
+const contextElement = document.querySelector('div');
+const result = contextElement.import('@context1#fragment2'); // Resolving to the module:/foo/nested#fragment2
+```
+#### Extended Scoped Module Contexts
-Here, we're able to have *one* element implement *both* at the same time - with scoped modules inheriting Import Contexts:
+Scoped Module Contexts may also have a Base Path Context that they inherit from:
 ```html
 <body contextname="context1" importscontext="/bar">
-  <section importscontext="nested"> <!-- object with own modules, plus inherited context: /bar/nested -->
+  <section importscontext="nested"> <!-- object with Scoped Modules, plus inherited context: /bar/nested -->
     <template def="foo" scoped> <!-- Scoped to host object and not available globally -->
       <div def="fragment1"></div>
@@ -559,33 +574,36 @@ Here, we're able to have *one* element implement *both* at the same time - with
     </template>
     <div>
-      <import ref="foo#fragment2"></import> <!-- Relative path (beginning without a slash), resolves to the local module: foo#fragment2, and if not found, resolves from context to the module: /bar/nested/foo#2 -->
-      <import ref="/foo#fragment1"></import> <!-- Absolute path, resolves to the global module: /foo#fragment1 -->
-      <import ref="@context1#fragment1"></import> <!-- Resolves to the global module: /bar#fragment1 -->
+      <import ref="foo#fragment2"></import> <!-- Relative path (beginning without a slash), resolving to the local module: foo#fragment2, and if not found, the inherited module: /bar/nested/foo#2 -->
+      <import ref="/foo#fragment1"></import> <!-- Absolute path, resolving to the global module: /foo#fragment1 -->
+      <import ref="@context1#fragment1"></import> <!-- Relative path with a named context, resolving to the global module: /bar#fragment1 -->
     </div>
   </section>
 </body>
 ```
+**-->** *with the `Element.prototype.import()` API for equivalent context-based imports*:
 ```js
 // Using the HTMLImports API
-const moduleHost = document.querySelector('div');
-const localOrGlobalImport2 = moduleHost.import('#fragment2'); // the local module: foo#fragment2, and if not found, resolves from context to the module: /bar/nested#fragment2
-console.log(localOrGlobalImport2); // { value: div }
+const contextElement = document.querySelector('div');
+const result = contextElement.import('#fragment2'); // the local module: foo#fragment2, and if not found, the inherited module: /bar/nested#fragment2
 ```
 </details>
 ## Data Binding
-Data binding is about declaratively binding the UI to application data, ensuring that the relevant parts of the UI are *automatically* updated as application state changes.
+Data binding is about declaratively binding the UI to application data, wherein the relevant parts of the UI *automatically* update as application state changes.
+OOHTML makes this possible in just simple conventions - via a new comment-based data-binding syntax `<?{ }?>` and a complementary new `expr` attribute!
-OOHTML makes this possible in just simple conventions - via a new comment-based data-binding syntax `<?{ }?>` and a complementary new `binding` attribute! And there's one more: Quantum Scripts which brings the most advanced form of reactivity to HTML!
+And there's one more: Quantum Scripts which brings the most advanced form of reactivity to HTML!
 ### Discrete Data-Binding
-Here, we get a comment-based data-binding tag `<?{ }?>` which works like regular comment but stay "data-charged":
+Here, we get a comment-based data-binding tag `<?{ }?>` which gives us a regular HTML comment but also an insertion point for application data:
 ```js
 <html>
@@ -599,9 +617,9 @@ Here, we get a comment-based data-binding tag `<?{ }?>` which works like regular
 </html>
 ```
-<details><summary>Details</summary>
+<details><summary>Resolution details</summary>
-Here, JavaScript references are resolved from the closest node up the document hierarchy that exposes a corresponding *binding* on its Bindings API ([discussed below](#bindings-api)). Thus, the above markup could have an underlying data structure like the below:
+Here, JavaScript references are resolved from the closest node up the document tree that exposes a corresponding *binding* on its Bindings API ([discussed below](#bindings-api)). Thus, for the above markup, our underlying data structure could be something like the below:
 ```js
 document.bind({ name: 'James Boye', cool: '100%', app: { title: 'Demo App' } });
@@ -615,7 +633,7 @@ document: { name: 'James Boye', cool: '100%', app: { title: 'Demo App' } }
   └── body: { name: 'John Doe' }
 ```
-So, above, the `name` reference remains bound to the `name` *binding* on the `<body>` element until the meaning of "closest node" changes again:
+Now, the `name` reference remains bound to the `name` *binding* on the `<body>` element until the meaning of "closest node" changes again:
 ```js
 delete document.body.bindings.name;
@@ -629,19 +647,19 @@ document.body.bindings.cool = '200%';
 </details>
-<details><summary>With SSR Support</summary>
+<details><summary>With SSR support</summary>
-On the server, these data-binding tags would retain their place in the DOM while having their output rendered to their right in a text node.
+On the server, these data-binding tags will retain their place in the DOM while having their output rendered to their right in a text node.
-The following: `<?{ 'Hello World' }?>` would thus give us: `<?{ 'Hello World' }?>Hello World`.
+The following expression: `<?{ 'Hello World' }?>` would thus give us: `<?{ 'Hello World' }?>Hello World`.
-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:
+But they also will need to remember the exact text node that they manage, so as to be able to re-establish relevant relationships 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 in the following form:
 ```html
 <?{ 'Hello World'; [=11] }?>Hello World
 ```
-Now that extra bit of information gets decoded and original relationships are forned again on getting to the client. But the binding tag itself graciously disappears from the DOM, while the now "hydrated" text node continues to kick!
+Now, on getting to the client, that extra bit of information gets decoded, and original relationships are forned again. But the binding tag itself graciously disappears from the DOM, while the now "hydrated" text node continues to kick!
 > Note: We know we're on the server when `window.webqit.env === 'server'`. This flag is automatically set by OOHTML's current SSR engine: [OOHTML-SSR](https://github.com/webqit/oohtml-ssr)
@@ -649,51 +667,51 @@ Now that extra bit of information gets decoded and original relationships are fo
 ### Inline Data-Binding
-Here, we get the `binding` attribute for a declarative and neat, key/value data-binding syntax:
+Here, we get the `expr` attribute for a declarative, neat, key/value data-binding syntax:
 ```html
-<div binding="<directive> <param>: <arg>;"></div>
+<div expr="<directive> <param>: <arg>;"></div>
 ```
 **-->** *where*:
-+ *`<directive>` is the directive, which is always a symbol*
++ *`<directive>` is a directive, which is always a symbol*
 + *`<param>` is the parameter being bound, which could be a CSS property, class name, attribute name, Structural Directive - depending on the givin directive*
 + *`<arg>` is the bound value or expression*
 **-->** *which would give us the following for a CSS property*:
 ```html
-<div binding="& color:someColor; & backgroundColor:'red'"></div>
+<div expr="& color:someColor; & backgroundColor:'red'"></div>
 ```
 **-->** *without being space-sensitive*:
 ```html
-<div binding="& color:someColor; &backgroundColor: 'red'"></div>
+<div expr="& color:someColor; &backgroundColor: 'red'"></div>
 ```
 **-->** *the rest of which can be seen below*:
 | Directive | Type | Usage |
 | :---- | :---- | :---- |
-| `&`  | CSS Property | `<div binding="& color:someColor; & backgroundColor:someBgColor;"></div>` |
-| `%`  | Class Name | `<div binding="% active:app.isActive; % expanded:app.isExpanded;"></div>` |
-| `~`  | Attribute Name | `<a binding="~ href:person.profileUrl+'#bio'; ~ title:'Click me';"></a>` |
-|   | Boolean Attribute | `<a binding="~ ?required:formField.required; ~ ?aria-checked: formField.checked"></a>` |
+| `&`  | CSS Property | `<div expr="& color:someColor; & backgroundColor:someBgColor;"></div>` |
+| `%`  | Class Name | `<div expr="% active:app.isActive; % expanded:app.isExpanded;"></div>` |
+| `~`  | Attribute Name | `<a expr="~ href:person.profileUrl+'#bio'; ~ title:'Click me';"></a>` |
+|   | Boolean Attribute | `<a expr="~ ?required:formField.required; ~ ?aria-checked: formField.checked"></a>` |
 | `@`  | Structural Directive: | *See below* |
-| `@text`   | Plain text content | `<span binding="@text:firstName+' '+lastName;"></span>` |
-| `@html`   | Markup content | `<span binding="@html: '<i>'+firstName+'</i>';"></span>` |
-|  `@items`  | A list, with argument in the following format:<br>`<declaration> <of\|in> <iterable> / <importRef>` | *See next two tables* |
+| `@text`   | Plain text content | `<span expr="@text:firstName+' '+lastName;"></span>` |
+| `@html`   | Markup content | `<span expr="@html: '<i>'+firstName+'</i>';"></span>` |
+|  `@items`  | A list, of the following format | `<declaration> <of\|in> <iterable> / <importRef>`<br>*See next two tables* |
 <details><summary><code>For ... Of</code> Loops</summary>
 |  Idea | Usage |
 | :---- | :---- |
-| A `for...of` loop over an array/iterable | `<ul binding="@items: value of [1,2,3] / 'foo#fragment';"></ul>` |
-| Same as above but with a `key` declaration  | `<ul binding="@items: (value,key) of [1,2,3] / 'foo#fragment';"></ul>` |
-| Same as above but with different variable names  | `<ul binding="@items: (product,id) of store.products / 'foo#fragment';"></ul>` |
-| Same as above but with a dynamic `importRef`  | `<ul binding="@items: (product,id) of store.products / store.importRef;"></ul>` |
+| A `for...of` loop over an array/iterable | `<ul expr="@items: value of [1,2,3] / 'foo#fragment';"></ul>` |
+| Same as above but with a `key` declaration  | `<ul expr="@items: (value,key) of [1,2,3] / 'foo#fragment';"></ul>` |
+| Same as above but with different variable names  | `<ul expr="@items: (product,id) of store.products / 'foo#fragment';"></ul>` |
+| Same as above but with a dynamic `importRef`  | `<ul expr="@items: (product,id) of store.products / store.importRef;"></ul>` |
 </details>
@@ -701,14 +719,14 @@ Here, we get the `binding` attribute for a declarative and neat, key/value data-
 | Idea | Usage |
 | :---- | :---- |
-| A `for...in` loop over an object | `<ul binding="@items: key in {a:1,b:2} / 'foo#fragment';"></ul>` |
-| Same as above but with a `value` and `index` declaration | `<ul binding="@items: (key,value,index) in {a:1, b:2} / 'foo#fragment';"></ul>` |
+| A `for...in` loop over an object | `<ul expr="@items: key in {a:1,b:2} / 'foo#fragment';"></ul>` |
+| Same as above but with a `value` and `index` declaration | `<ul expr="@items: (key,value,index) in {a:1, b:2} / 'foo#fragment';"></ul>` |
 </details>
-<details><summary>Details</summary>
+<details><summary>Resolution details</summary>
-Here, JavaScript references are resolved from the closest node up the document hierarchy that exposes a corresponding *binding* on its Bindings API ([discussed below](#bindings-api)). Thus, the above CSS example code could have an underlying data structure like the below:
+Here, JavaScript references are resolved from the closest node up the document tree that exposes a corresponding *binding* on its Bindings API ([discussed below](#bindings-api)). Thus, for the above CSS bindings, our underlying data structure could be something like the below:
 ```js
 document.bind({ someColor: 'green', someBgColor: 'yellow' });
@@ -722,7 +740,7 @@ document: { someColor: 'green', someBgColor: 'yellow' }
   └── body: { someBgColor: 'silver' }
 ```
-So, above, the `someBgColor` reference remains bound to the `someBgColor` *binding* on the `<body>` element until the meaning of "closest node" changes again:
+Now, the `someBgColor` reference remains bound to the `someBgColor` *binding* on the `<body>` element until the meaning of "closest node" changes again:
 ```js
 delete document.body.bindings.someBgColor;
@@ -742,9 +760,9 @@ Bindings are resolved in realtime! And in fact, for lists, in-place mutations -
 </details>
-<details><summary>With SSR Support</summary>
+<details><summary>With SSR support</summary>
-For lists, generated item elements are automatically assigned a corresponding index with a `data-index` attribute! This helps in remapping generated item nodes to their respective entry in *iteratee* - universally.
+For lists, generated item elements are automatically assigned a corresponding key with a `data-key` attribute! This helps in remapping generated item nodes to their respective entry in *iteratee* during a rerendering or during hydration.
 </details>
@@ -752,7 +770,7 @@ For lists, generated item elements are automatically assigned a corresponding in
 We often still need to write more serious reactive logic on the UI than a declarative data-binding language can provide for. But we shouldn't need to reach for special tooling or some "serious" programming paradigm on top of JavaScript.
-Here, from the same `<script>` element we already write, we get a direct upgrade path to reactive programming in just an attribute: `quantum`:
+Here, from the same `<script>` element we already write, we get a direct upgrade path to reactive programming in just the addition of an attribute: `quantum`:
 ```html
 <script quantum>
@@ -768,7 +786,7 @@ Here, from the same `<script>` element we already write, we get a direct upgrade
 </script>
 ```
-**-->** *which adds up really well with the idea of scoping*:
+**-->** *which gives us fine-grained reactivity on top of literal JavaScript syntax; and which adds up really well with the `scoped` attribute*:
 ```html
 <main>
@@ -792,7 +810,7 @@ Here, from the same `<script>` element we already write, we get a direct upgrade
 </main>
 ```
-**-->** *with content being whatever you normally would write in a `<script>` element, but without the "manual" work for reactivity*:
+**-->** *with content being whatever you normally would write in a `<script>` element, minus the "manual" work for reactivity*:
 ```html
 <main>
@@ -810,7 +828,7 @@ Here, from the same `<script>` element we already write, we get a direct upgrade
 </main>
 ```
-**-->** *within which other "live" APIs, like the Namespace API above, fit seamlessly*:
+**-->** *within which dynamic application state/data, and even things like the Namespace API above, fit seamlessly*:
 ```html
 <main namespace>
@@ -843,13 +861,13 @@ const removeButton = () => {
 };
 ```
-<details><summary>Details</summary>
+<details><summary>Learn more</summary>
 It's Imperative Reactive Programming ([IRP](https://en.wikipedia.org/wiki/Reactive_programming#Imperative)) right there and it's the [Quantum](https://github.com/webqit/quantum-js) runtime extension to JavaScript!
 Here, the runtime executes your code in a special execution mode that gets literal JavaScript expressions to statically reflect changes. This makes a lot of things possible on the UI! The [Quantum JS](https://github.com/webqit/quantum-js) documentation has a detailed run down.
-Now, in each case above, reactivity terminates on script's removal from the DOM. And a programmatic termination is sill possible:
+Now, in each case above, reactivity terminates on script's removal from the DOM or via a programmatic approach:
 ```js
 const script = document.querySelector('script[quantum]');
@@ -863,115 +881,397 @@ But while that is automatic, DOM event handlers bound via `addEventListener()` w
 ## Data Plumbing
-*[TODO]: Bindings API & The Context API*
-<!--
-The last set of features covers the concept of "state", "bindings", and "reactivity" for those objects at the DOM level - in the most exciting form of the terms and as an upgrade path! This comes factored into the design as something intrinsic to the problem.
+Components often need to manage, or be managed by, dynamic data. That could get pretty problematic and messy if all of that should go on DOM nodes as direct properties:
-└ *The [Observer API](https://github.com/webqit/observer) for general-purpose object observability*:
+<details><summary>Example</summary>
 ```js
-function changeCallback(changes) {
-    console.log(changes[0].type, changes[0].key, changes[0].value, changes[0].oldValue);
+// Inside a custom element
+connectedCallback() {
+  this.prop1 = 1;
+  this.prop2 = 2;
+  this.prop3 = 3;
+  this.style = 'tall-dark'; // ??? - conflict with the standard HTMLElement: style property
 }
 ```
 ```js
-const obj = {};
-Observer.observe(obj, changeCallback);
+// Outside the component
+const node = document.querySelector('my-element');
+node.prop1 = 1;
+node.prop2 = 2;
+node.prop3 = 3;
+node.normalize = true; // ??? - conflict with the standard Node: normalize() method
+```
+</details>
+This calls for a decent API and some data-flow mechanism!
+### The Bindings API
+A place to maintain state need not be a complex state machine! Here, that comes as a simple, read/write, data object exposed on the document object and on DOM elements as a readonly `bindings` property. This is the Bindings API.
+**-->** *it's an ordinary JavaScript object that can be read and mutated*:
+```js
+// Read
+console.log(document.bindings); // {}
+// Modify
+document.bindings.app = { title: 'Demo App' };
+console.log(document.bindings.app); // { title: 'Demo App' }
+```
+```js
+const node = document.querySelector('div');
+// Read
+console.log(node.bindings); // {}
+// Modify
+node.bindings.style = 'tall-dark';
+node.bindings.normalize = true;
 ```
+**-->** *with a complementary `bind()` method that lets us make mutations in batch*:
 ```js
-Observer.set(obj, 'prop1', 'value1'); // Reported synchronously
+// ------------
+// Set multiple properties
+document.bind({ name: 'James Boye', cool: '100%', app: { title: 'Demo App' } });
+// ------------
+// Replace existing properties with a new set
+document.bind({ signedIn: false, hot: '100%' });
+// Inspect
+console.log(document.bindings); // { signedIn: false, hot: '100%' }
+// ------------
+// Merge a new set of properties with existing
+document.bind({ name: 'James Boye', cool: '100%' }, { merge: true });
+// Inspect
+console.log(document.bindings); // { signedIn: false, hot: '100%', name: 'James Boye', cool: '100%' }
 ```
+**-->** *which also provides an easy way to passing data down a component tree*:
 ```js
-Observer.deleteProperty(obj, 'prop1'); // Reported synchronously
+// Inside a custom element
+connectedCallback() {
+  this.child1.bind(this.bindings.child1Data);
+  this.child2.bind(this.bindings.child2Data);
+}
 ```
-└ *A Bindings API for binding application-level state to an object*:
+**-->** *and with the Observer API in the picture for reactivity*:
 ```js
-// Observing document-level bindings
-Observer.observe(document.bindings, changeCallback);
+Observer.observe(document.bindings, mutations => {
+  mutations.forEach(mutation => console.log(mutation));
+});
+```
-// Set state
-document.bindings.userSignedIn = true;
+```js
+// Inside a custom element
+connectedCallback() {
+  Observer.observe(this.bindings, 'style', e => {
+    // Compunonent should magically change style
+    console.log(e.value);
+  });
+}
+```
-// Set data object
-document.bindings.data = { prop1: 'value1' };
-Observer.set(document.bindings.data, 'prop2', 'value2');
+```js
+const node = document.querySelector('my-element');
+node.bindings.style = 'tall-dark';
 ```
+<details><summary>Details</summary>
+In the current OOHTML implementation, the `document.bindings` and `Element.prototype.bindings` APIs are implemented as proxies over their actual bindings interface to enable some interface-level reactivity. This lets us have reactivity over literal property assignments and deletions on these interfaces:
 ```js
-// Observing element-level bindings
-Observer.observe(element.bindings, changeCallback);
+node.bindings.style = 'tall-dark'; // Reactive assignment
+delete node.bindings.style; // Reactive deletion
+```
-// Set state
-element.bindings.isCollapsed = true;
+For mutations at a deeper level to be reactive, the corresponding Observer API method must be used:
-// Set data object
-element.bindings.data = { prop1: 'value1' };
-Observer.set(element.bindings.data, 'prop2', 'value2');
+```js
+Observer.set(document.bindings.app, 'title', 'Demo App!!!');
+Observer.deleteProperty(document.bindings.app, 'title');
 ```
-└ *"Quantum Scripts" for reactive scripting*:
+</details>
-```html
-<script quantum>
-  console.log(this) // window
+### The Context API
+Component trees on the typical UI often call for more than the normal top-down flow of data that the Bindings API facilitates. A child may require the ability to look up the component tree to directly access specific data, or in other words, get data from "context". This is where a Context API comes in.
-  console.log(window.liveProperty) // live expression
-  console.log(liveProperty) // live expression; technically same as above
+Interestingly, the Context API is the underlying resolution mechanism for HTML Imports and Data Binding in OOHTML!
+Here, we simply leverage the DOM's existing event system to fire a "request" event and let an arbitrary "provider" in context fulfill the request. This becomes very simple with the Context API which is exposed on the document object and on element instances as a readonly `contexts` property.
+**-->** *with the `contexts.request()` method for firing requests*:
+```js
+// ------------
+// Get an arbitrary
+const node = document.querySelector('my-element');
+// ------------
+// Prepare and fire request event
+const requestParams = { kind: 'html-imports', detail: '/foo#fragment1' };
+const response = node.contexts.request(requestParams);
+// ------------
+// Handle response
+console.log(response.value); // It works!
+```
-  if (document.bindings.userSignedIn) {
-      // Live block
-      console.log('User signed in!');
+**-->** *and the `contexts.attach()` and  `contexts.detach()` methods for attaching/detaching providers at arbitrary levels in the DOM tree*:
+```js
+// ------------
+// Define a CustomContext class
+class FakeImportsContext extends DOMContext {
+  static kind = 'html-imports';
+  handle(event) {
+    console.log(event.detail); // '/foo#fragment1'
+    event.respondWith('It works!');
   }
-</script>
+}
+// ------------
+// Instantiate and attach to a node
+const fakeImportsContext = new FakeImportsContext;
+document.contexts.attach(fakeImportsContext);
+// ------------
+// Detach anytime
+document.contexts.detach(fakeImportsContext);
 ```
+<details><summary>Details</summary>
+In the current OOHTML implementation, the Context API interfaces are exposed via the global `webqit` object:
 ```js
-Observer.set(window, 'liveProperty'); // Live expressions rerun
+const { DOMContext, DOMContextRequestEvent, DOMContextResponse } = window.webqit;
 ```
-```html
-<div>
-  <script quantum scoped>
-    console.log(this) // div
+Now, by design...
++ a provider will automatically adopt the `contextname`, if any, of its host element:
+    ```html
+    <div contextname="context1"></div>
+    ```
+    ```js
+    // Instantiate and attach to a node
+    const host = document.querySelector('div');
+    const fakeImportsContext = new FakeImportsContext;
+    host.contexts.attach(fakeImportsContext);
+    // Inspect name
+    console.log(fakeImportsContext.name); // context1
+    ```
+    ...which a request could target:
-    console.log(this.liveProperty) // live expression
+    ```js
+    const requestParams = { kind: FakeImportsContext.kind, targetContext: 'context1', detail: '/foo#fragment1' };
+    const response = node.contexts.request(requestParams);
+    ```
++ and providers of same kind could be differentiated by an extra "detail" - an arbitrary value passed to the constructor:
+    ```js
+    const fakeImportsContext = new FakeImportsContext('lorem');
+    console.log(fakeImportsContext.detail); // lorem
+    ```
-    if (this.bindings.isCollapsed) {
-        // Live block
-        console.log('Section collapsed!');
++ and a provider could indicate to manually match requests where the defualt "kind" matching, and optional "targetContext" matching, don't suffice:
+    ```js
+    // Define a CustomContext class
+    class CustomContext extends DOMContext {
+      static kind = 'html-imports';
+      matchEvent(event) {
+        // The default request matching algorithm + "detail" matching
+        return super.matchEvent() && event.detail === this.detail;
+      }
+      handle(event) {
+        console.log(event.detail);
+        event.respondWith('It works!');
+      }
     }
-  </script>
+    ```
++ and a request could choose to stay subscribed to changes on the requested data; the request would simply add a `live` flag:
+    ```js
+    // Set the "live" flag
+    const requestParams = { kind: FakeImportsContext.kind, targetContext: 'context1', detail: '/foo#fragment1', live: true };
+    ```
+    ...then stay alert to said updates on the returned `DOMContextResponse` object or specify a callback function at request time:
+    ```js
+    // Handle response without a callback
+    const response = node.contexts.request(requestParams);
+    console.log(response.value); // It works!
+    Observer.observe(response, 'value', e => {
+      console.log(e.value); // It works live!
+    });
+    ```
+    ```js
+    // Handle response with a callback
+    node.contexts.request(requestParams, value => {
+      console.log(value);
+      // It works!
+      // It works live!
+    });
+    ```
+    ...while provider simply checks for the `event.live` flag and keep the updates flowing:
+    ```js
+    // Define a CustomContext class
+    class CustomContext extends DOMContext {
+      static kind = 'html-imports';
+      handle(event) {
+        event.respondWith('It works!');
+        if (event.live) {
+          setTimeout(() => {
+            event.respondWith('It works live!');
+          }, 5000);
+        }
+      }
+    }
+    ```
+    ...and optionally implements a `subscribed` and `unsubscribed` lifecycle hook for when a "live" event enters and leaves the instance:
+    ```js
+    // Define a CustomContext class
+    class CustomContext extends DOMContext {
+      static kind = 'html-imports';
+      subscribed(event) {
+        console.log(this.subscriptions.size); // 1
+      }
+      unsubscribed(event) {
+        console.log(this.subscriptions.size); // 0
+      }
+      handle(event) {
+        event.respondWith('It works!');
+        if (event.live) {
+          setTimeout(() => {
+            event.respondWith('It works live!');
+          }, 5000);
+        }
+      }
+    }
+    ```
++ live requests are terminated via the returned `DOMContextResponse` object...
+    ```js
+    response.abort();
+    ```
+    ...or via an initially specified custom `AbortSignal`:
+    ```js
+    // Add a signal to the original request
+    const abortController = new AbortController;
+    const requestParams = { kind: FakeImportsContext.kind, targetContext: 'context1', detail: '/foo#fragment1', live: true, signal: abortController.signal };
+    ```
+    ```js
+    abortController.abort(); // Which also calls response.abort();
+    ```
++ now, when a node in a provider's subtree is suddenly attached an identical provider, any live requests the super provider may be serving are automatically "claimed" by the sub provider:
+    ```js
+    document: // 'fake-provider' here
+    └── html
+      ├── head
+      └── body:  // 'fake-provider' here. Our request above is now served from here.
+    ```
+    And when the sub provider is suddenly detached from said node, any live requests it may have served are automatically hoisted back to super provider.
+    ```js
+    document: // 'fake-provider' here. Our request above is now served from here.
+    └── html
+      ├── head
+      └── body:
+    ```
+    While, in all, saving the requesting code that "admin" work!
+</details>
+**-->** *all of which gives us the imperative equivalent of declarative context-based features like HTMLImports and Data Binding*:
+```html
+<div contextname="vendor1">
+  <div contextname="vendor2">
+    ...
+      <my-element>
+        <!-- Declarative import -->
+        <import ref="@vendor1/foo#fragment1"></import>
+        <!-- Declarative Data Binding -->
+        <?{ @vendor2.app.title }?>
+      </my-element>
+    ...
+  </div>
 </div>
 ```
 ```js
-Observer.set(element, 'liveProperty'); // Live expressions rerun
+// ------------
+// Equivalent import() approach
+const response = myElement.import('@vendor1/foo#fragment1');
+// ------------
+// Equivalent Context API approach
+const requestParams = { kind: 'html-imports', targetContext: 'vendor1', detail: 'foo#fragment1' };
+const response = myElement.contexts.request(requestParams);
+// ------------
+// Handle response
+console.log(response.value);
 ```
-└ [Reactive HTML concepts](#)
+```js
+// ------------
+// Context API request for bindings
+const requestParams = { kind: 'bindings', targetContext: 'vendor2', detail: 'app' };
+const response = myElement.contexts.request(requestParams);
--->
+// ------------
+// Handle response
+console.log(response.value.title);
+```
 ## Polyfill
-OOHTML is being developed as something to be used today—via a polyfill. This is an active and intentional effort that continues to ensure that the project evolves through a practice-driven process.
+OOHTML is being developed as something to be used today—via a polyfill. This is an intentional effort that's helping to ensure that the project evolves through a practice-driven process.
 <details><summary>Load from a CDN<br>
-└───────── <a href="https://bundlephobia.com/result?p=@webqit/oohtml"><img align="right" src="https://img.shields.io/bundlephobia/minzip/@webqit/oohtml?label=&style=flat&colorB=black"></a></summary>
+└───────── <a href="https://bundlephobia.com/result?p=@webqit/oohtml"><img align="right" src="https://img.shields.io/badge/21.7%20kB-black"></a></summary>
 ```html
-<script src="https://unpkg.com/@webqit/oohtml/dist/main.js"></script>
+<script src="https://unpkg.com/@webqit/oohtml/dist/main.lite.js"></script>
 ```
 └ This is to be placed early on in the document and should be a classic script without any `defer` or `async` directives!
-└ For the Scoped Styles feature, you'd also need something like the [samthor/scoped](https://github.com/samthor/scoped) polyfill (more details below):
+└ For the Scoped Styles feature, you'd need an external polyfill like the [samthor/scoped](https://github.com/samthor/scoped) polyfill (more details below):
 ```html
 <head>
@@ -985,18 +1285,19 @@ OOHTML is being developed as something to be used today—via a polyfill. This i
 └───────── <a href="https://npmjs.com/package/@webqit/oohtml"><img align="right" src="https://img.shields.io/npm/v/@webqit/oohtml?style=flat&label=&colorB=black"></a></summary>
 ```bash
-npm i @webqit/oohtml
+npm i @webqit/oohtml @webqit/quantum-js
 ```
 ```js
 // Import
+import * as Quantum from '@webqit/quantum-js/lite'; // Or from '@webqit/quantum-js'; See implementation notes below
 import init from '@webqit/oohtml';
 // Initialize the lib
-init.call( window[, options = {} ]);
+init.call(window, Quantum[, options = {}]);
 ```
-└ To use the polyfill on server-side DOM instances as made possible by libraries like [jsdom](https://github.com/jsdom/jsdom), simply install and initialize the library `@webqit/oohtml` with the DOM instance as above.
+└ To use the polyfill on server-side DOM instances as made possible by libraries like [jsdom](https://github.com/jsdom/jsdom), simply install and initialize the library with the DOM instance as above.
 └ But all things "SSR" for OOHTML are best left to the [`@webqit/oohtml-ssr`](https://github.com/webqit/oohtml-ssr) package!
@@ -1004,24 +1305,36 @@ init.call( window[, options = {} ]);
 <details><summary>Extended usage concepts</summary>
-If you'll be going ahead to build a real app to see OOHTML in action, you may want to consider also using:
+If you'll be going ahead to build a real app with OOHTML, you may want to consider also using:
 + the [`@webqit/oohtml-cli`](https://github.com/webqit/oohtml-cli) package for operating a file-based templating system.
-+ the modest, OOHTML-based [Webflo](https://github.com/webqit/webflo) framework to greatly streamline your application development process!
++ the modest, OOHTML-based [Webflo](https://github.com/webqit/webflo) framework to greatly streamline your workflow!
 </details>
 <details><summary>Implementation Notes</summary>
++ **Scoped/Quantum Scripts**. This feature is an extension of [Quantum JS](https://github.com/webqit/quantum-js). While the main OOHTML build is based on the main Quantum JS APIs, a companion "OOHTML Lite" build is also available based on the [Quantum JS Lite](https://github.com/webqit/quantum-js#quantum-js-lite) edition. The trade-off is in the execution timing of `<script quantum></script>` and `<script scoped></script>` elements: being "synchronous/blocking" with the former, and "asynchronous/non-blocking" with the latter! (See [`async`/`defer`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script#attributes).)
+    Of the two, the "OOHTML Lite" edition is the recommend option (as used above) for faster load times unless there's a requirment to have classic scripts follow their [native synchronous timing](https://html.spec.whatwg.org/multipage/parsing.html#scripts-that-modify-the-page-as-it-is-being-parsed), in which case you'd need the main OOHTML build:
+    ```html
+    <head>
+      <script src="https://unpkg.com/@webqit/oohtml/dist/main.js"></script>
+    </head>
+    ```
+    └─ <a href="https://bundlephobia.com/result?p=@webqit/oohtml"><img align="right" src="https://img.shields.io/bundlephobia/minzip/@webqit/oohtml?label=&style=flat&colorB=black"></a>
 + **Loading Requirements**. As specified above, the OOHTML script tag is to be placed early on in the document and should be a classic script without any `defer` or `async` directives!
-    If you must load the script "async", one little trade-off has to be made for `<script scoped>` and `<script quantum>` elements to have them ignored by the browser until the polyfill comes picking them up: *employing a custom MIME type in place of the standard `text/javascript` and `module` types*, in which case, a `<meta name="scoped-js">` element is used to configure the polyfill to honor the custom MIME type:
+    If you must load the script "async", one little trade-off would have to be made for `<script scoped>` and `<script quantum>` elements to have them ignored by the browser until the polyfill comes picking them up: *employing a custom MIME type in place of the standard `text/javascript` and `module` types*, in which case, a `<meta name="scoped-js">` element is used to configure the polyfill to honor the custom MIME type:
     ```html
     <head>
       <meta name="scoped-js" content="script.mimeType=some-mime">
-      <script async src="https://unpkg.com/@webqit/oohtml/dist/main.js"></script>
+      <script async src="https://unpkg.com/@webqit/oohtml/dist/main.lite.js"></script>
     </head>
     <body>
       <script type="some-mime" scoped>
@@ -1042,16 +1355,6 @@ If you'll be going ahead to build a real app to see OOHTML in action, you may wa
     ...still gives the `window` object in the console.
-+ **Scoped/Quantum Scripts**. This feature is an extension of [Quantum JS](https://github.com/webqit/quantum-js) and the default OOHTML build is based on the [Quantum JS Lite APIs](https://github.com/webqit/quantum-js#quantum-js-lite). Now, while Quantum JS Lite yields faster load times, it also means that `<script quantum></script>` and `<script scoped></script>` elements are parsed "asynchronously", in the same timing as `<script type="module"></script>`!
-    This timing works perfectly generally, but if you have a requirment to have classic scripts follow their [native synchronous timing](https://html.spec.whatwg.org/multipage/parsing.html#scripts-that-modify-the-page-as-it-is-being-parsed), then you'd need to use the *realtime* OOHTML build:
-    ```html
-    <head>
-      <script src="https://unpkg.com/@webqit/oohtml/dist/main.realtime.js"></script>
-    </head>
-    ```
 + **Scoped CSS**. This feature is only in "concept" implementation and doesn't work right now as is. The current implementation simply wraps `<style scoped>` blocks in an `@scope {}` block - which itself isn't supported in any browser. To try this "concept" implementation, set the `style.strategy` config to `@scope`:
     ```html
@@ -1100,7 +1403,7 @@ If you'll be going ahead to build a real app to see OOHTML in action, you may wa
 ## Examples
-Here are a few examples in the wide range of use cases these features cover. While we'll demonstrate the most basic forms of these scenarios, it takes roughly the same principles to build an intricate form and a highly interactive UI.
+Here are a few examples in the wide range of use cases these features cover. While we'll demonstrate the most basic form of these scenarios, it takes roughly the same principles to build an intricate form and a highly interactive UI.
 <details><summary>Example 1: <i>Single Page Application</i><br>
 └───────── </summary>
@@ -1295,11 +1598,11 @@ The following is a hypothetical list page!
   <!-- The "items" template -->
   <template def="item" scoped>
-    <li><a binding="~href: '/animals#'+name;"><?{ index+': '+name }?></a></li>
+    <li><a expr="~href: '/animals#'+name;"><?{ index+': '+name }?></a></li>
   </template>
   <!-- The loop -->
-  <ul binding="@items: (name,index) of ['dog','cat','ram'] / 'item';"></ul>
+  <ul expr="@items: (name,index) of ['dog','cat','ram'] / 'item';"></ul>
 </section>
 ```