Web Components

[josepharhar]

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

https://wpt.fyi/results/css/cssom?label=experimental&label=master&aligned&view=subtest&q=adopt%20or%20construct

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

https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Imperative-Shadow-DOM-Distribution-API.md

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

Spec

https://html.spec.whatwg.org/C/#css-module-script

[gsnedders]

FWIW: I do wonder if we should split this up into smaller proposals, rather than as a single massive one. I think it'll be easier both from a review point of view and from the point of view of keeping track of comments on it if it were split up?

[jgraham]

Strong +1 to splitting this up; people should be aware that the process will judge all 10 sub-issues here as one large proposal and so anything that is objectionable in any of them will cause the whole proposal to fail. Splitting allows some parts to succeed and others to fail.

For the parts which are cleaning up existing features, if the test failures are known to correspond to observed problems for users or authors, they may be good candidates for #187

[mfreed7]

Strong +1 to splitting this up; people should be aware that the process will judge all 10 sub-issues here as one large proposal and so anything that is objectionable in any of them will cause the whole proposal to fail. Splitting allows some parts to succeed and others to fail.

That's too bad. Is the process this year the same as it was for Interop2022? I seem to remember some "negotiation" for Interop2022 on what exactly to include in each category, which was quite healthy and ended up with a good set of tests and ideas for each one.

I feel like having a general group, rather than 10 separate areas, will help summarize status and progress. If we definitely need to split this up, perhaps we could have 1) Custom Elements, 2) Shadow DOM, and 3) Other Web Components Stuff ?

@josepharhar nice work putting this together.

[foolip]

We did change the process a little bit for Interop 2023, so that we have an opportunity to group proposals in a second step. This makes it more practical to have fine-grained proposals, but what the ideal size of a proposal is is something we're discovering as we go.

@gsnedders @jgraham do you splitting into the 3 bits @mfreed7 suggests would suffice?

For an overview, here are the top-level sections:

• Miscellaneous Shadow DOM
• Miscellaneous Custom Elements
• Form-associated Custom Elements
• Declarative Shadow DOM
• adoptedStyleSheets
• Imperative slot assignment
• CSS Shadow Parts
• Custom Builtins
• CSS Custom State
• Import Assertions
• CSS Modules

I guess splitting like this would be mechanically straightforward, but I'm not sure if there are dependencies that could result in nonsensical combinations of those proposals.

[josepharhar]

If we definitely need to split this up, perhaps we could have 1) Custom Elements, 2) Shadow DOM, and 3) Other Web Components Stuff ?

Here is how I would organizing them:

• Custom Elements
  • Miscellaneous Custom Elements
  • Form-associated Custom Elements
  • Custom Builtins
• Shadow DOM
  • Miscellaneous Shadow DOM
  • Declarative Shadow DOM
  • Imperative slot assignment
• Other Web Components Features
  • adoptedStyleSheets
  • CSS Shadow Parts
  • CSS Custom State
  • Import Assertions
  • CSS Modules

I guess splitting like this would be mechanically straightforward, but I'm not sure if there are dependencies that could result in nonsensical combinations of those proposals.

I think the only dependencies to worry about are import assertions and css modules, which I think might be highly related.

anything that is objectionable in any of them will cause the whole proposal to fail

If that is the case then I'm going to have to file all 11 separately. However, when I proposed the forms category last year the type=week and type=month tests were rejected but the rest of the proposal continued just fine.

[foolip]

These proposals filed by @Westbrook (thanks!) overlap to some degree or another with this proposal:

• Form-Associated Custom Elements #203
• Constructable Stylesheets & adoptedStyleSheets #204
• CSS Module Scripts #206
• Imperative Slot Assignment #207

I'm not sure if #208 also overlaps, but it is in the Web Components space.

[Westbrook]

Happy to help, excited to see so many Web Components ideas in the running for this!

I was posting with my Web Components Community Group Chair Person hat on. The above issues are what we saw as immediately actionable APIs from our presentation to TPAC last month.

[EisenbergEffect]

This is great to see!

Observation: Everything under "Other Web Components Features" seems to relate to styling (import assertions is more general but currently used to enable CSS Script Modules). Perhaps we rename this group to "Styling Web Components" or "Component/CSS Inerop"?

[LeviPesin]

Other Web Components Features
adoptedStyleSheets
CSS Shadow Parts
CSS Custom State
Import Assertions
CSS Modules

Maybe split this further on "CSS Features" (first three) and "Import/Modules Features" (last two, and possibly include JSON modules, and also maybe include my import maps issue)?

[foolip]

There's also possible overlap with these proposals:

• :host(:has(...)) pointing to light DOM content #208
• @font-face and @property constructs in Shadow Roots #212
• Composed Selection (Selection APIs for Shadow DOM) #216

I didn't look closer than the issue titles so far, just want to flag this for review.

[josepharhar]

I have split the 11 subcategories of this issue into separate issues:

1. form-associated custom elements was merged into Form-Associated Custom Elements #203
2. adoptedStyleSheets was merged into Constructable Stylesheets & adoptedStyleSheets #204
3. CSS Modules was merged into CSS Module Scripts #206
4. Imperative slot assignment was merged into Imperative Slot Assignment #207
5. Miscellaneous shadow DOM was separated into Miscellaneous Shadow DOM #230
6. Miscellaneous custom elements was separated into Miscellaneous Custom Elements #231
7. declarative shadowdom was separated into Declarative Shadow DOM #232
8. CSS shadow parts was separated into CSS Shadow Parts #233
9. Custom builtins was separated into Custom Builtins #234
10. CSS custom state was separated into CSS Custom State #235
11. Import assertions was separated into Import Assertions #236

I'm guessing this also means that this issue should be closed now

[foolip]

Thanks @josepharhar, and sorry that I didn't predict that this would need splitting, that could have saved you some trouble here.