@webqit/oohtml 2.1.78 → 2.1.80
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.
- package/README.md +8 -8
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -237,9 +237,9 @@ Here, we get an `<import>` element that lets us do that declaratively:
|
|
|
237
237
|
|
|
238
238
|
<details><summary>All in Realtime</summary>
|
|
239
239
|
|
|
240
|
-
As a realtime module system, `<import> `elements maintain a live relationship with given module definition `<template def>`
|
|
240
|
+
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:
|
|
241
241
|
+ the `<import>` element points to another module — either by `ref` change or by a change in `importscontext` (below).
|
|
242
|
-
+ the module definition `<template def>`
|
|
242
|
+
+ the module definition element (`<template def>`) has had its contents updated, either programmatically or automatically from having loaded.
|
|
243
243
|
|
|
244
244
|
Conversely, an `<import>` element that has been resolved will self-restore in the event that:
|
|
245
245
|
+ the `<import>` element no longer points to a module; or the module has been emptied or removed.
|
|
@@ -262,7 +262,7 @@ The above resolved imports would thus give us something like:
|
|
|
262
262
|
</body>
|
|
263
263
|
```
|
|
264
264
|
|
|
265
|
-
But they also
|
|
265
|
+
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:
|
|
266
266
|
|
|
267
267
|
```html
|
|
268
268
|
<!--<import ref="/foo/nested#fragment2" nodecount="1"></import>-->
|
|
@@ -362,7 +362,7 @@ setTimeout(() => abortController.abort(), 1000);
|
|
|
362
362
|
|
|
363
363
|
We can defer module loading until we really need them.
|
|
364
364
|
|
|
365
|
-
Here, we get the `loading="lazy"` directive for that:
|
|
365
|
+
Here, we get the `loading="lazy"` directive for that; and loading is only then triggered on the first attempt to import its contents:
|
|
366
366
|
|
|
367
367
|
```html
|
|
368
368
|
<!-- Loading doesn't happen until the first time this is being accessed -->
|
|
@@ -380,7 +380,7 @@ const moduleObject2 = document.import('/foo#fragment1'); // Triggers module load
|
|
|
380
380
|
|
|
381
381
|
### Scoped Modules
|
|
382
382
|
|
|
383
|
-
Some modules will only be relevant within a specific context in the page.
|
|
383
|
+
Some modules will only be relevant within a specific context in the page, and these shouldn't map to the global document scope.
|
|
384
384
|
|
|
385
385
|
Here, we get the `scoped` attribute for scoping those to their respective contexts, and thus, implicitly have an *object-scoped* module system:
|
|
386
386
|
|
|
@@ -572,7 +572,7 @@ OOHTML makes this possible in just simple conventions - via a new comment-based
|
|
|
572
572
|
|
|
573
573
|
### Discrete Data-Binding
|
|
574
574
|
|
|
575
|
-
Here, we get a comment-based data-binding
|
|
575
|
+
Here, we get a comment-based data-binding tag `<?{ }?>` which works like regular comment but stay "data-charged":
|
|
576
576
|
|
|
577
577
|
```js
|
|
578
578
|
<html>
|
|
@@ -592,7 +592,7 @@ On the server, these data-binding tags would retain their place in the DOM while
|
|
|
592
592
|
|
|
593
593
|
The following: `<?{ 'Hello World' }?>` would thus give us: `<?{ 'Hello World' }?>Hello World`.
|
|
594
594
|
|
|
595
|
-
But they also
|
|
595
|
+
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:
|
|
596
596
|
|
|
597
597
|
```html
|
|
598
598
|
<?{ 'Hello World'; [=11] }?>Hello World
|
|
@@ -860,7 +860,7 @@ Also, if you'll be going ahead to build a real app to see OOHTML in action, you
|
|
|
860
860
|
|
|
861
861
|
+ **Scoped/Stateful Scripts**. This feature is an extension of [Stateful JS](https://github.com/webqit/stateful-js). The default OOHTML build is based on the [Stateful JS Lite APIs](https://github.com/webqit/stateful-js#stateful-js-lite) and this means that `<script stateful></script>` and `<script scoped></script>` elements are parsed "asynchronously", in the same timing as `<script type="module"></script>`!
|
|
862
862
|
|
|
863
|
-
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 need to the *realtime* OOHTML build:
|
|
863
|
+
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:
|
|
864
864
|
|
|
865
865
|
```html
|
|
866
866
|
<head>
|