diff --git a/2022.html b/2022.html index b9c9f6c..c7946b2 100644 --- a/2022.html +++ b/2022.html @@ -132,6 +132,10 @@ "name": "Alan Dávalos", "url": "https://github.com/alangdm" }, + { + "name": "Rob Eisenberg", + "url": "https://github.com/eisenbergeffect" + }, { "name": "Owen Buckley", "url": "https://github.com/thescientist13" @@ -171,6 +175,8 @@

Web Components Community Group: 2022 Spec/API statu Westbrook Johnson
Alan Dávalos +
+ Rob Eisenberg
Owen Buckley
@@ -343,15 +349,15 @@

Web Components Community Group: 2022 Spec/API statu Lazy custom element definitions + WICG/webcomponents#782 - - + Uncertain DOM Parts + DOM Part API - First Step of Template Instantiation - - + Uncertain HTML modules @@ -361,9 +367,9 @@

Web Components Community Group: 2022 Spec/API statu Custom Attributes + Web Components CG Discussion - - + Not addressed --- @@ -1092,51 +1098,116 @@

Web Components Community Group: 2022 Spec/API statu
Previous WCCG Report(s)
2021
GitHub issues:
-
---
+
+ +
Browser positions:
---

12.2 Description

-

---

+

A method of creating custom elements completely with declarative HTML, not requiring JavaScript.

12.3 Status

    -
  • ---
    • +
  • Strawperson proposal available.
    • +
  • Dependent on many other proposals that are not yet finished.
    • +
  • Many people would like to have something like this but it seems too early due to the number of unfinished dependencies.

12.4 Initial API Summary/Quick API Proposal

-

Summary or proposal based on current status; paragraph(s) and code.

+

The following, copied from the original strapwerson proposal, demonstrates how a declarative custom element could be defined with the need for JavaScript.

+ 
<definition name="percentage-bar">
+    <template shadowmode="closed">
+        <div id="progressbar" role="progressbar" aria-valuemin="0" aria-valuemax="100" aria-valuenow="{{\root.attributes.percentage.value}}">
+            <div id="bar" style="width: {{\root.attributes.percentage.value}}%"></div>
+            <div id="label"><slot></slot></div>
+        </div>
+        <style>
+            :host { display: inline-block !important; }
+            #progressbar { position: relative; display: block; width: 100%; height: 100%; }
+            #bar { background-color: #36f; height: 100%; }
+            #label { position: absolute; top: 0px; left: 0px; width: 100%; height: 100%; text-align: center; }
+        </style>
+    </template>
+</definition>

12.5 Key Scenarios

-

---

+
    +
  • Create reusable custom elements without needing to load or run JavaScript.
    • +
  • Use custom elements in noscript contexts.
    • +
  • Open up new opportunities for more efficient server-side-rendering. e.g. Smaller html payloads due to less duplication of HTML
    • +
  • Codify framework "single file component" patterns in the platform.
    • +

12.6 Concerns

    -
  • ---
    • +
  • Binding syntax for attributes is extremely verbose. e.g. "{{root.attributes.percentage.value}}" is used instead of something terser like "{{percentage}}" .
    • +
  • Binding syntax doesn't look extensible.
    • +
  • A lot of cooperation from tooling and plugin authors will be required to enable developer ergonomics and adoption.
    • +
  • The current proposal's script model creates a second way of coding components with some different behavior from what we have today.
    • +
  • The current proposal conflicts in syntax with Declarative Shadow DOM.

12.7 Dissenting Opinion

-
    -
  • ---
    • -
+

No dissenting opinions yet.

12.9 Open Questions

    -
  • ---
    • +
  • Shouldn't attributes be declared instead of inferred through the bindings?
    • +
  • How to handle boolean attributes and reflected attributes?
    • +
  • If script is provided through src, how should loading be handled? Does it block or can it be partially upgraded?
    • +
  • How does this support aria roles, degegated aria, and cross-root aria?
    • +
  • How is form association handled?
    • +
  • When script is provided, how does it interact with or gain access to the template and styles?
    • +
  • Should there be ways to ship definitions along with a data set or top-level template so that small payloads of data can be automatically combined with template and element declarations without the need for JS?
@@ -1428,51 +1499,154 @@

Web Components Community Group: 2022 Spec/API statu
Previous WCCG Report(s)
N/A
GitHub issues:
-
---
+
+ +
Browser positions:
---

18.2 Description

-

---

+

+ Enable the browser to automatically load a custom element definition when it first sees the associated tag. +

18.3 Status

    -
  • ---
    • +
  • + Strawperson proposal available. +
    • +
  • + There is further disagreement as to whether this feature is needed. However, the community generally tends to lean toward wanting some version of this. +
    • +
  • + There are many open questions around the feature-set as well as how it interoperates with other proposals. +

18.4 Initial API Summary/Quick API Proposal

-

Summary or proposal based on current status; paragraph(s) and code.

+

Below is a definition for the proposed new CustomElementRegistry API.

+ 
  CustomElementRegistry#defineLazy(tagName: string, loader: () => Promise);
+

18.5 Key Scenarios

-

---

+

+

    +
  • + Enable bundlers to split code based on the presence of dynamic import calls. Tools like guess.js can integrate with bundlers to provide statistical analysis of actual usage, optimizing bundles better. This proposal would enable that type of integration. +
    • +
  • + Enable consumers of web components to not have to worry about handling the loading of the code in every place where a component is used. This is important in systems where the content may leverage a potential large number of Web Components but where only a few are actually needed in any given experience. E.g. News sites, feeds, etc. +
    • +
  • + Firefox has an internal API for lazy loading definitions. +
    • +
+

18.6 Concerns

    -
  • ---
    • +
  • + This feature could make it easy to create a "loading pyramid". e.g. Component A loads, which causes B and C to load, which then cause D and E to load, etc. +

18.7 Dissenting Opinion

    -
  • ---
    • +
  • + Breaks Principle of Least Surprise. If you see a component in the HTML, you expect to be able to interact with it. But this may fail due to the component not being loaded yet. +
    • +
  • + Seems backward to have the browser tell the experience when to load code, rather than the experience telling the browser. +
    • +
  • + Rather than focusing on this high level feature, we should instead add low-level APIs that enable building this feature with a few lines of code. Recognizes that MutationObserver is not sufficient, but isn't convinced about lazy definitions. +

18.9 Open Questions

    -
  • ---
    • +
  • + How do we handle ElementDefinitionOptions? CustomElementDefinition isn't defined in the proposal above. Does it include this? How? +
    • +
  • + Should there be a parallel API to unload a definition? +
    • +
  • + Should there be additional configuration options for load triggers? +
      +
    • + When certain attributes change. +
      • +
    • + When certain events are fired. +
      • +
    • + When scrolled into view. +
      • +
    • + When the mouse is close. +
      • +
    +
    • +
  • + How does this work with sync calls to document.createElement? +
    • +
  • + Should there be wild card registrations that can be used to load collections of components based on a pattern? +
    • +
  • + Could all of this be handled by a more general-purpose callback that was simply fired when an unknown element name is seen? +
    • +
  • + How do we handle lazy definitions when someone calls "get" on the CustomElementsRegistry? +
    • +
  • + If a component is lazy defined but has not yet loaded, what happens when someone tries to synchronously define an element with the same name? +
    • +
  • + How does a component know when all its lazily loaded children are done loading? +
    • +
  • + Should there be a more declarative API for this to tell the parser where to fine unknown elements? +
@@ -1484,51 +1658,146 @@

Web Components Community Group: 2022 Spec/API statu
Previous WCCG Report(s)
N/A
GitHub issues:
-
---
+
+ +
Browser positions:
---

19.2 Description

-

---

+

A mechanism to insert or replace content at specific locations within the DOM tree.

19.3 Status

    -
  • ---
    • +
  • Strawperson proposal available.
    • +
  • General consensus is that this is needed and could be used by existing Web Component and Frontend libraries and frameworks.
    • +
  • Lots of bike shedding over naming.
    • +
  • There is a large number of open questions both on this feature and how it interacts with other proposals.

19.4 Initial API Summary/Quick API Proposal

-

Summary or proposal based on current status; paragraph(s) and code.

+

The following is a summary of the core types from the proposal.

+ 
interface Part {
+    attribute any value;
+    void commit();
+};
+
+
+interface NodePart : Part {
+    readonly attribute Node node;
+};
+
+
+interface AttributePart : Part {
+    constructor(Element element, DOMString qualifiedName, DOMString? namespace);
+    readonly attribute DOMString prefix;
+    readonly attribute DOMString localName;
+    readonly attribute DOMString namespaceURI;
+};
+
+
+interface ChildNodePart : Part {
+    constructor(Node node, Node? previousSibling, Node? nextSibling);
+    readonly attribute Node parentNode;
+    readonly attribute Node? previousSibling;
+    readonly attribute Node? nextSibling;
+}

19.5 Key Scenarios

-

---

+

+

    +
  • + Enable batched updates to the DOM, usable by library/framework view engines. Library authors would be able to remove part of their user-land solution, shrinking libraries and reducing JS execution. +
    • +
  • + Needed as a steppingstone towards reactive bindings for custom elements. +
    • +
+

19.6 Concerns

    -
  • ---
    • +
  • + Naming the API as "Part" could cause confusion with CSS Shadow Parts. No consensus over naming reached yet. +

19.7 Dissenting Opinion

    -
  • ---
    • +
  • + Some individuals, particularly from React-ish backgrounds, would prefer a diffing-based alternative to batched updates. However, there are several problems with the diffing proposal. +
      +
    • + The core proposal shows diffing between real DOM nodes, which is very heavy. +
      • +
    • + The diffing proposal acknowledges the above flaw and attempts to solve it by proposing a JavaScript API to create virtual DOMs but it's unclear why existing libraries can't be used for this. +
      • +
    • + It is not clear how this maps to fully declarative templates down the road, which are created in real DOM. +
      • +
    +

19.9 Open Questions

    -
  • ---
    • +
  • + How to handle attribute parts when there is a mixture of static and dynamic parts needed to assemble the attribute value? +
    • +
  • + How to handle child node updates when there is a mixture of elements, text, etc. that are potentially changing. +
    • +
  • + How to handle setting properties? +
    • +
  • + How do libraries and frameworks handle custom behaviors/directives? +
    • +
  • + How do we handle batches of updates and ordering of updates? +
    • +
  • + How do we clone templates to efficiently reproduce the template content and the proper part setup? +
    • +
  • + Could part references be shared with workers to allow DOM updates from workers? +
@@ -1596,51 +1865,124 @@

Web Components Community Group: 2022 Spec/API statu
Previous WCCG Report(s)
N/A
GitHub issues:
-
---
+
+ +
Browser positions:
---

21.2 Description

-

---

+

Enable developers to create reusable custom behaviors that that can be declaratively applied to any element.

21.3 Status

    -
  • ---
    • +
  • + No official proposal yet. +
    • +
  • + While there is no official issue for this yet, this feature request crops up in several discussions on other threads. In general, the community seems to be very interested in having something like this. +

21.4 Initial API Summary/Quick API Proposal

-

Summary or proposal based on current status; paragraph(s) and code.

+

There is no issue or proposal yet. The following can serve as an initial idea, inspired by custom elements.

+ 
  class MaterialRipple extends Attr {
+    // ownerElement inherited from Attr
+    // name inherited from Attr
+    // value inherited from Attr
+    // ...
+
+    connectedCallback () {
+      // called when the ownerElement is connected to the DOM
+    }
+
+    disconnectedCallback () {
+      // called when the ownerElement is disconnected from the DOM
+    }
+
+    attributeChangedCallback() {
+      // called when the value property of this attribute changes
+    }
+}
+
+customAttributes.define("material-ripple", MaterialRipple);

21.5 Key Scenarios

-

---

+

+

    +
  • Enable more built-in patterns to be accomplishable by developer extensions. e.g. label for, img src
    • +
  • Enable behaviors to be written once and used on any element.
    • +
  • May serve as a better solution than the "is" capability of custom elements (which isn't fully supported).
    • +
+

21.6 Concerns

-
    -
  • ---
    • -
+

No concerns yet.

21.7 Dissenting Opinion

-
    -
  • ---
    • -
+

No dissenting opinions yet.

21.9 Open Questions

    -
  • ---
    • +
  • + How should custom attributes be named? Can they follow the same hyphen convention as custom elements? +
    • +
  • + SVG has some CSS properties that it surfaces as attributes. How do we prevent conflicts? +
    • +
  • + It could be beneficial for a custom attribute to have access to the shadow DOM of a custom element, but is this a security issue? +
    • +
  • + Should we allow access to ElementInternals? Is that a security problem? Is there a limited version of this we could support? Do custom elements need to allow this? What about built-ins? +
    • +
  • + How to handle when "removeAttribute" is called? +
    • +
  • + Should there be special handling for boolean attributes? +
    • +
  • + Should there be a specific set of pre-defined attributes that can be opted into for custom elements. e.g. for, src +