@webqit/oohtml 3.1.10 → 3.1.12
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 +5 -5
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -27,7 +27,7 @@ Amidst a multitude of approaches, vanilla HTML remains an attractive option for
|
|
|
27
27
|
|
|
28
28
|
OOHTML comes, not as a specific technology, but as a conceptual "framework" of features that solves for HTML as an object-oriented language - whether that means re-aligning existing features or introducing new ones! While features may be discussed or explored individually, the one agenda "Object-Oriented HTML" helps us stay aligned with the original problem! Each of these features has been introduced below with a small explainer.
|
|
29
29
|
|
|
30
|
-
OOHTML is effectively different from Web Components (and from the related Declarative Custom Elements and Declarative Shadow DOM efforts) in its focus on "arbitrary" HTML and the DOM rather than on just the Custom Element or Shadow DOM "subset" of the language. This in
|
|
30
|
+
OOHTML is effectively different from Web Components (and from the related Declarative Custom Elements and Declarative Shadow DOM efforts) in its focus on "arbitrary" HTML and the DOM rather than on just the Custom Element or Shadow DOM "subset" of the language. This in turn lets us have a niftier authoring experience in Web Components as the latter actually just relies on the very HTML and DOM.
|
|
31
31
|
|
|
32
32
|
</details>
|
|
33
33
|
|
|
@@ -48,7 +48,7 @@ OOHTML makes this possible by introducing "namespacing" and style and script sco
|
|
|
48
48
|
|
|
49
49
|
Naming things is hard! That's especially so where you have one global namespace and a miriad of potentially conflicting names to coordinate!
|
|
50
50
|
|
|
51
|
-
Here, we get the `namespace` attribute
|
|
51
|
+
Here, we get a modular naming convention using the `namespace` attribute. This attribute let's us designate an element as naming context for identifiers in given subtree:
|
|
52
52
|
|
|
53
53
|
```html
|
|
54
54
|
<div id="user" namespace>
|
|
@@ -128,7 +128,7 @@ console.log(window.foo); // div
|
|
|
128
128
|
|
|
129
129
|
We often need a way to keep component-specific stylesheets and scripts [scoped to a component](https://vuejs.org/guide/scaling-up/sfc.html). **This is especially crucial to "page components" in an SPA architecture.**
|
|
130
130
|
|
|
131
|
-
Here, we get
|
|
131
|
+
Here, we get a new `scoped` attribute that lets us do just that:
|
|
132
132
|
|
|
133
133
|
```html
|
|
134
134
|
<div>
|
|
@@ -163,7 +163,7 @@ Here, the `scoped` attribute has two effects on the `<script>` element:
|
|
|
163
163
|
|
|
164
164
|
HTML Imports is a realtime *import* system for HTML that's drawn entirely on HTML - and that's worlds apart from [the abandoned `<link type="import">` feature](https://www.w3.org/TR/html-imports/) and the [HTML Modules proposal](https://github.com/WICG/webcomponents/blob/gh-pages/proposals/html-modules-explainer.md)! **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.**
|
|
165
165
|
|
|
166
|
-
Here, we get a way to
|
|
166
|
+
Here, we get a way to both define and use a snippet within *same* document:
|
|
167
167
|
|
|
168
168
|
```html
|
|
169
169
|
<head>
|
|
@@ -264,7 +264,7 @@ foo.addEventListener('error', errorCallback);
|
|
|
264
264
|
|
|
265
265
|
### Declarative Module Imports
|
|
266
266
|
|
|
267
|
-
HTML snippets should be reusable
|
|
267
|
+
HTML snippets should be reusable entirely out of HTML! So, we get an `<import>` element that lets us do just that:
|
|
268
268
|
|
|
269
269
|
```html
|
|
270
270
|
<body>
|