Web Components #181
Description
Description
This category includes tests for Shadow DOM and Custom Elements, which are used together to create Web Components.
Rationale
https://w3c.github.io/webcomponents-cg/#introduction
The initial slate of APIs that browsers shipped with web components "v1" left many important features and use-cases on a future to-do list, to be finalized out after the core custom element and shadow DOM features landed.
More detailed rationale for each feature is listed next to its tests.
Specification
The specification for each subsection is listed next to its tests.
Tests
Miscellaneous Shadow DOM
Description
This is a bunch of WPTs in the shadow-dom directory that are failing. I don’t think they correspond to any particular big feature, they were just made from random one-off bugs.
Rationale
Basic Shadow DOM behavior should be interoperable.
Shadow DOM focus navigation, delegatesFocus, and element.focus()
Tests:
https://wpt.fyi/results/shadow-dom/focus-navigation
https://wpt.fyi/results/shadow-dom/focus
Spec:
https://html.spec.whatwg.org/C/#focus-processing-model
https://html.spec.whatwg.org/C/#sequential-focus-navigation
Shadow DOM events and retargeting
Tests:
https://wpt.fyi/results/shadow-dom/DocumentOrShadowRoot-prototype-elementFromPoint.html
https://wpt.fyi/results/shadow-dom/MouseEvent-prototype-offsetX-offsetY.html
https://wpt.fyi/results/shadow-dom/capturing-and-bubbling-event-listeners-across-shadow-trees.html
Spec:
- https://drafts.csswg.org/cssom-view-1/#dom-document-elementfrompoint
- MouseEvent is defined here but there is no definition for offsetX or offsetY: https://w3c.github.io/uievents/#idl-mouseevent
- capturing-and-bubbling-event-listeners-across-shadow-trees.html was discussed here: Composed and non bubbling event semantic dispatched in shadow tree whatwg/dom#742
Miscellaneous Custom Elements
Description
This is a bunch of WPTs in the custom-elements directory that are failing. I don’t think they correspond to any particular big feature, they were just made from random one-off bugs.
Rationale
Basic custom elements behavior should be interoperable.
Callbacks
Tests:
https://wpt.fyi/results/custom-elements/adopted-callback.html
https://wpt.fyi/results/custom-elements/reactions
Custom Element Registry
Tests:
https://wpt.fyi/results/custom-elements/custom-element-registry
https://wpt.fyi/results/custom-elements/CustomElementRegistry.html
Spec: https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements-api
Construction
Tests:
https://wpt.fyi/results/custom-elements/Document-createElement.html
https://wpt.fyi/results/custom-elements/Document-createElementNS.html
https://wpt.fyi/results/custom-elements/htmlconstructor
https://wpt.fyi/results/custom-elements/HTMLElement-constructor.html
https://wpt.fyi/results/custom-elements/range-and-constructors.html
https://wpt.fyi/results/custom-elements/perform-microtask-checkpoint-before-construction.html
https://wpt.fyi/results/custom-elements/perform-microtask-checkpoint-before-construction-xml-parser.xhtml
https://wpt.fyi/results/custom-elements/throw-on-dynamic-markup-insertion-counter-construct-xml-parser.xhtml
https://wpt.fyi/results/custom-elements/throw-on-dynamic-markup-insertion-counter-reactions-xml-parser.xhtml
Spec:
https://html.spec.whatwg.org/multipage/dom.html#html-element-constructors
Parsing and Serializing
Tests: https://wpt.fyi/results/custom-elements/parser
Spec:
https://html.spec.whatwg.org/C/#create-an-element-for-the-token
https://dom.spec.whatwg.org/#concept-create-element
:defined Pseudo Selector
Tests:
https://wpt.fyi/results/custom-elements/pseudo-class-defined-print.html
https://wpt.fyi/results/custom-elements/pseudo-class-defined.html
Spec: https://html.spec.whatwg.org/multipage/semantics-other.html#selector-defined
Upgrading
Tests: https://wpt.fyi/results/custom-elements/upgrading
Spec: https://html.spec.whatwg.org/C/#upgrades
Form-associated Custom Elements
Description
https://w3c.github.io/webcomponents-cg/#form-associated-custom-elements
Form-associated custom elements allow custom elements to participate in forms to the same degree as native elements, including integrations with the form’s validation, state, and submission as well as exposing the Accessibility Object Model to the element.
Rationale
https://w3c.github.io/webcomponents-cg/#form-associated-custom-elements
One of the most common use cases for web components is creating form controls not available natively. Some examples include switches and credit card inputs.
Tests
https://wpt.fyi/results/custom-elements/element-internals-shadowroot.html
https://wpt.fyi/results/custom-elements/form-associated
https://wpt.fyi/results/custom-elements/HTMLElement-attachInternals.html
Spec
https://html.spec.whatwg.org/#element-internals
Declarative Shadow DOM
Description
https://w3c.github.io/webcomponents-cg/#declarative-shadow-dom
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.
Rationale
https://w3c.github.io/webcomponents-cg/#declarative-shadow-dom
Without Declarative Shadow DOM, web components depend on rendering environments that support JavaScript. This limits their use in server-side rendering and javascript-less environments.
Tests
https://wpt.fyi/results/shadow-dom/declarative
Spec
whatwg/dom#892
whatwg/html#5465
adoptedStyleSheets
Description
https://w3c.github.io/webcomponents-cg/#constructable-stylesheets-adoptedstylesheets
Constructable Stylesheets and adoptedStyleSheets enable adding styles directly to 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.
Rationale
https://w3c.github.io/webcomponents-cg/#constructable-stylesheets-adoptedstylesheets
- There is no effective way to share styles across components while allowing them to be centrally modified.
- Creating <style> elements for each style used in each shadow root has a measurable performance overhead.
- CSS Module Scripts, another critical feature, depends on constructible stylesheets.
Tests
Spec
https://w3c.github.io/csswg-drafts/cssom-1/#dom-documentorshadowroot-adoptedstylesheets
Imperative slot assignment
Description
Imperative slot assignment adds an assign() method to slot elements so their light-DOM nodes can be assigned from script instead of declaratively from HTML.
Rationale
Tests
https://wpt.fyi/results/shadow-dom?q=imperative
Spec
https://html.spec.whatwg.org/C/#dom-slot-assign
whatwg/html#6561
whatwg/dom#966
CSS Shadow Parts
Description
https://drafts.csswg.org/css-shadow-parts/#intro
The ::part() pseudo-element allows an author to style specific, purposely exposed elements in a shadow tree from the outside page’s context.
Rationale
https://drafts.csswg.org/css-shadow-parts/#motivation
For custom elements to be fully useful and as capable as built-in elements it should be possible for parts of them to be styled from outside. Exactly what can be styled from outside should be controlled by the element author. Also, it should be possible for a custom element to present a stable "API" for styling. That is, the selector used to style a part of a custom element should not expose or require knowledge of the internal details of the element. The custom element author should be able to change the internal details of the element while leaving the selectors untouched.
Tests
https://wpt.fyi/results/css/css-shadow-parts
Spec
https://drafts.csswg.org/css-shadow-parts
Custom Builtins
Tests
https://wpt.fyi/results/custom-elements/builtin-coverage.html
https://wpt.fyi/results/custom-elements/customized-built-in-constructor-exceptions.html
Spec
https://html.spec.whatwg.org/multipage/custom-elements.html#customized-built-in-element
CSS Custom State
Description & Rationale
https://github.com/WICG/custom-state-pseudo-class/blob/main/explainer.md
Built-in elements 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 web authors might want to expose these states in a similar fashion as the built-in elements. With the proposed states property on ElementInternals, custom element authors can add and modify custom states for the custom elements, and allow them to be selected with the :state() selector.
Tests
https://wpt.fyi/results/custom-elements/state
Spec
https://wicg.github.io/custom-state-pseudo-class/
Import Assertions
Description
https://chromestatus.com/feature/5765269513306112
Import Assertions are an inline syntax for module import statements to pass on more information alongside the module specifier.
Rationale
https://chromestatus.com/feature/5765269513306112
Standards-track JSON ES modules were proposed to allow JavaScript modules to easily import JSON data files, similarly to how they are supported in many nonstandard JavaScript module systems. This idea quickly got broad support from web developers and browsers, and was merged into HTML, with an implementation for V8/Chromium created by Microsoft.
However, security concerns were raised about privilege escalation that could occur when importing JSON modules and similar module types which cannot execute code. When a script imports something that it intends to be a JSON module, if the responding server unexpectedly provides a different MIME type then it could cause code to be unexpectedly executed. The solution was to somehow indicate that a module was JSON, or in general, not to be executed, somewhere in addition to the MIME type. Import Assertions provide the means for doing so.
Proposed ES module types that are blocked by this security concern, in addition to JSON modules, include CSS modules and potentially HTML modules if the HTML module proposal is restricted to not allow script.
Tests
https://wpt.fyi/results/html/semantics/scripting-1/the-script-element/import-assertions
Spec
https://tc39.es/proposal-import-assertions/
CSS Modules
Description
https://w3c.github.io/webcomponents-cg/#css-module-scripts
CSS Module Scripts allow JavaScript modules to import style sheets. They can then be applied to a document or shadow root using adoptedStyleSheets in the same way as constructible style sheets.
Rationale
https://w3c.github.io/webcomponents-cg/#css-module-scripts
- CSS modules will allow styles to be loaded in component definitions without adding <style> or elements that need to be created in each element instance.
- Authors today often use inlined CSS strings in JS modules, but many of them want to move the CSS into separate .css files.
- Without CSS-in-JS it's difficult to ensure that CSS is loaded before the component is defined and rendered. CSS module scripts provide the same ordering guarantee.
- Component authors may need to import a resource that is only available as an external .css file, and don't have control over the resource to wrap it in a JS module.
Tests
https://wpt.fyi/results/html/semantics/scripting-1/the-script-element/css-module