---
+The form-associated custom elements APIs enable custom elements to participate in form submission and validation lifecycles.
ElementInternals which includes the form-associated custom elements behavior; however, the initial PR doesn't include the actual form-association APIs.
+ Summary or proposal based on current status; paragraph(s) and code.
+The form-associated custom elements APIs are implemented within the attachInternals method on the HTMLElement prototype. Calling attachInternals returns an instance of an ElementInternals object which grants developers the ability to interact with form elements provided they designate their element as a form-associated element.
+
+
+ %gt;form>
+ %gt;fancy-input name="fancy">%gt;/fancy-input>
+ %gt;/form>
+
+ %gt;script>
+ class FancyInput extends HTMLElement {
+ static get formAssociated() {
+ return true;
+ }
+
+ constructor() {
+ super();
+ this.#internals = this.attachInternals();
+ this.#internals.setFormValue('I can participate in a form!');
+ }
+ }
+
+ customElements.define('fancy-input', FancyInput);
+
+ document.querySelector('form').addEventListener('submit', event => {
+ event.preventDefault();
+ const formData = new FormData(event.target);
+
+ console.log(formData.get('fancy')); // logs 'I can participate in a form!'
+ });
+ %gt;/script>
+
+
+ The setFormValue method can accept several types of data including strings, FileData and FormData objects, the latter of which can allow a nested form to participate with a parent in its entirety.
In addition to providing an method for adding a value to a form object, the form-associated APIs provide a surface to allow custom elements to participate in form validation.
+
+
+class FancyInput extends HTMLElement {
+ static get formAssociated() {
+ return true;
+ }
+
+ constructor() {
+ super();
+ const root = this.attachShadow({ mode: 'open' });
+ this.#internals = this.attachInternals();
+ this.#internals.setFormValue('I can participate in a form!');
+ const button = document.createElement('button');
+ root.append(button);
+
+ button.addEventListener('click', this.#onClick);
+ this.button = button;
+ }
+
+ #onClick = () => {
+ if (this.#internals.invalid) {
+ this.#internals.setValidity(); // Marks the element as valid
+ } else {
+ this.#internals.setValidity({
+ customError: true
+ }, 'You must click the button', this.button); // Marks the element as invalid and will focus on the button when the form checks validity
+ }
+}
+
+
---
-FormData object, adding to the HTMLFormElement.prototype.elements object and in other submission formats.CustomStateSet
+ formStateRestoreCallback callback only for restore events (such as back button or page refresh), but does not call the custom element reaction for autocomplete. Firefox currently does not ship any code referencing the formStateRestoreCallback.
+
+ ---
++ Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patters outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM. While there are ways to develop these UIs by orchestrating the relationships between elements of synthesizing the passing of content across a shadow boundary, these practices generally position accessible development out of reach for most developers, both at component creation and component consumption time. +
++ Developers of a custom element should be able to outline to browsers how content from outside of their shadow root realtes to the content within it and visa versa. Cross-root ARIA Delegation would allow developers to define how content on the outside is mapped to the content within a shadow root, while Cross-root ARIA Reflection would define how content within a shadow root was made available to content outside of it. +
+ Implementors participating in bi-weekly Accessibility Object Model syncs with WICG have all been favorable to the delegation work and are interested in the reflection work as a tighly related API that maybe is a fast follower. Leo Balter is working on finalizing proposal text for the delegation API at which time Westbrook Johnson will apply similar teminology to the reflection API proposal. +
Summary or proposal based on current status; paragraph(s) and code.
+HTML
+
+
+ <span id="foo">Description!</span>
+ <template id="template1">
+ <input id="input" autoarialabel autoariadescribedby />
+ <span autoarialabel>Another target</span>
+ </template>
+ <x-foo aria-label="Hello!" aria-describedby="foo"></x-foo>
+
+
+ JS
+
+
+ const template = document.getElementById('template1');
+
+ class XFoo extends HTMLElement {
+ constructor() {
+ super();
+ this.attachShadow({ mode: "open", delegatesAriaLabel: true, delegatesAriaDescribedBy: true });
+ this.shadowRoot.appendChild(template.content.cloneNode(true));
+ }
+ }
+
+ customElements.define("x-foo", XFoo);
+
+
+ HTML
+
+
+ <input aria-controlls="foo" aria-activedescendent="foo">Description!</span>
+ <template id="template1">
+ <ul reflectariacontrols>
+ <li>Item 1</li>
+ <li reflectariaactivedescendent>Item 2</li>
+ <li>Item 3</li>
+
+ </template>
+ <x-foo id="foo"></x-foo>
+
+
+ JS
+
+
+ const template = document.getElementById('template1');
+
+ class XFoo extends HTMLElement {
+ constructor() {
+ super();
+ this.attachShadow({ mode: "open", reflectsAriaControls: true, reflectsAriaActivedescendent: true });
+ this.shadowRoot.appendChild(template.content.cloneNode(true));
+ }
+ }
+ customElements.define("x-foo", XFoo);
+
+
---
-When developing many of the patterns outlines in the ARIA Authoring Practices Guide having this capability would allow for encapsulating responsibilities outlined by the `role` attribute in a shadow root.
---
+Constructable Stylesheets and adoptedStyleSheets enable adding styles directly to DOM trees, e.g. `document` and shadow roots, without creating new DOM elements. Because a single stylesheet object can be adopted by multiple scopes, it also allows sharing of styles that can be centrally modified.
Summary or proposal based on current status; paragraph(s) and code.
+The following is an example of what this would look like in practice.
+
+ const sheet = new CSSStyleSheet();
+ sheet.replaceSync('a { color: red; }');
+
+ // Apply the stylesheet to a document:
+ document.adoptedStyleSheets = [sheet];
+
+ // Apply the stylesheet to a Shadow Root:
+ const node = document.createElement('div');
+ const shadow = node.attachShadow({ mode: 'open' });
+ shadow.adoptedStyleSheets = [sheet];
+
---
+From their standards position tracker, Safari has highlighted some of the following concerns:
+---
+Scoped element registries allow custom element definitions to be scoped to one or more shadow roots. This allows the same tag name to be used with different implementations in different parts of the page, greatly reducing tag name collisions.
---
+---
+Declarative Shadow DOM is a mechanism to express Shadow DOM using only HTML, with no dependency on JavaScript, much like light DOM can be declaratively expressed today.
Summary or proposal based on current status; paragraph(s) and code.
++
+ <host-element> + <template shadowroot="open"> + <slot></slot> + </template> + <h2>Light content</h2>> + </host-element> ++
---
+Server-Side Rendering: Without Declarative Shadow DOM, servers cannot deliver complete websites that include web component content. Markup cannot be efficiently delivered and then hydrated with JavaScript client-side.
+JavaScript-less environments: Many web components could be implemented without JavaScript, taking advantage of encapsulated DOM and styles. However, web components cannot currently be rendered by users who have JavaScript disabled. Developers who are more comfortable with markup than with scripting may avoid shadow DOM altogether due to its tight coupling with JavaScript..
---
+A method of creating custom elements completely with declarative HTML, not requiring JavaScript.
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>
+
---
+No dissenting opinions yet.
---
+ ++Build-in elements provided by user agents have certain “states” that can change over time depending on user interaction and other factors, and are exposed to web authors through pseudo classes. For example, some form controls have the “invalid” state, which is exposed through the :invalid pseudo-class.
+ +Like built-in elements, custom elements can have various states to be in too, and custom element authors want to expose these states in a similar fashion as the built-in elements.
+
Summary or proposal based on current status; paragraph(s) and code.
+The CustomStateSet API allows component authors to expose internal component state for use in styling or other element-matching operations (such as querySelector
This is different from a custom element sprouting a class (via this.classList.add in any state added to the custom element can be seen as internal (similar to the :checked pseud-selector for input elements).
To allow for this operation, a set-like API is exposed at ElementInternals.prototype.states, meaning that only custom elements can apply custom states. An example might look like the following:
+
+class FancyElement extends HTMLElement {
+ #internals = this.attachInternals();
+
+ constructor() {
+ super();
+
+ const root = this.attachShadow({ mode: 'open' });
+ const button = document.createElement('button');
+ button.innerText = 'Add clicked state';
+ button.setAttribute('part', 'btn');
+ root.append(button);
+
+ this.addEventListener('click', function wasClicked() {
+ this.#internals.states.add('--clicked');
+ this.removeEventListener('click', wasClicked);
+ });
+ }
+}
+customElements.define('fancy-element', FancyElement);
+
+
+
+ Consumers of the fancy-element code can now take advantage of the :--clicked state in CSS or in any DOM querying API to modify or select the relevant element once clicked.
For example, to change the background of the element's btn part, a consuming developer could apply the following CSS:
+
+:--clicked::part(btn) {
+ background: rebeccapurple;
+}
+
+
+
+ Alternatively, a consuming developer could call document.querySelectorAll(':--clicked') to target all elements with the custom state.
---
-:state(--state); however, it appears as if the current status is fairly accepted right now.---
++ Enable the browser to automatically load a custom element definition when it first sees the associated tag. +
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); +
---
++
---
+A mechanism to insert or replace content at specific locations within the DOM tree.
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;
+ }
+
---
++
---
+Enable developers to create reusable custom behaviors that that can be declaratively applied to any element.
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);
+
---
++
No concerns yet.
No dissenting opinions yet.