Web Components at TPAC 2023

This year’s W3C TPAC (Technical Plenary and Advisory Committee) was held in Seville, Spain, on September 11–15, and featured an entire track dedicated to Web Components and related standards. It was a huge success thanks to great participation from both the community and the major browser vendors. Special thanks go out to the W3C Web Components Community Group chaired by Westbrook Johnson (Adobe) and to Ryosuke Niwa of WebKit (Apple) for planning sessions and helping with the overall logistics.

Let’s run through the various breakout sessions from the event.

IMPORTANT: If you want to learn more about Web Components as well as dozens of related Web Standards, check out my upcoming “Web Component Engineering” course. Between now and the launch on Nov. 7, I’m running a presale. Use code EARLYBIRD at checkout to save $100 on this 13 module, 170+ video course with a fully interactive learning environment!

Session: Web Components API/Specs Report and Alignment

The first breakout session was led by the W3C Web Components Community Group. Each year the group presents a review of the previous year’s standards alignment progress and helps highlight for browser implementors which specs are most critical to get shipped in the upcoming year.

Priorities identified by the CG based on a community survey were:

• Declarative Shadow DOM
• Scoped Custom Element Registries
• Cross-root ARIA
• CSS Slot Content Detection

Declarative Shadow DOM

Declarative Shadow DOM (DSD) is an already standardized way of representing Shadow DOM trees directly in HTML without the need for JavaScript. It is key to enabling SSR of Web Components that use Shadow DOM technology, but also helpful outside of Web Components, when HTML markup is needed for rendering concerns rather than semantics.

The group’s goal in this session was to emphasize the importance of this standard and see what could be done to get full browser parity. The highlight of the hour, and perhaps the day, was when Firefox shared that they were working on DSD and intended to ship it very soon, which would achieve the group’s goal of full browser parity!

Scoped Custom Element Registry

Today, all Web Components are defined in the browser global custom elements registry which affects the document and all shadow roots. The scoped registry proposal would enable developers to create their own custom registries, which when associated with a shadow root, would make only the elements in their registry available in the shadow root.

The CG spent time during this session emphasizing the importance of this kind of modularity and scoping to larger scale apps and asked for browser vendors to consider prototyping the functionality. The spec is mostly complete, but a few final details still need work and could likely be addressed through the prototyping process. A breakout session later in the day was planned to explore the topic further (see below).

Cross Shadow Root ARIA

Accessibility is a complex topic and when it comes to Shadow DOM, there are distinct challenges. The CG talked through the various challenges and specs under consideration, with special emphasis on the new Export Id proposal. Microsoft showed interest in prototyping. A breakout session was planned for later in the day to discuss options further (see below).

CSS Slot Content Detection

When building components, a common styling scenario involves needing to style various elements based on whether a slot has assigned nodes or not. Today, that has to be handled with custom JavaScript. The community request is to add a new CSS selector that would enable handling this in a fully declarative fashion.

Currently, discussion on this topic is happening in the CSS Working Group but it needs feedback from browser implementors.

Features Browsers are Interested In

After reviewing the Web Component Community Group’s top requests, time was taken to hear the top requests from browser implementors as well. Browser vendors expressed continued interested in Web Components as a whole. In fact, they shared a particular growing interest in getting to some form of declarative custom elements soon. Firefox in particular was very interested in this as a potential boost to performance in certain scenarios, based on some past work they had done with caching and binary representations of declarative components (in XBL).

CG Plans for 2024

The CG and vendors committed to setting up quarterly face-to-face meetings in the coming year, to facilitate more aggressive forward progress in key spec areas. It was decided that the new f2f meeting sequence will have an improved format to ensure conclusions and action items are better captured as well, with implementor participation as a key goal.

Session: Scoped Custom Element Registry

During the session on Scoped Custom Element Registries, the core features of the proposal were enumerated first:

• Enable programmatic creation of custom element registries, which are then assigned when the shadow root is attached.
• Every shadow root either uses a scoped registry or a global registry, which is determined once at creation time.
• New APIs should be added to shadow roots to enable element creation based on the assigned registry. e.g shadowRoot.createElement(...)
• innerHTML and similar APIs which already use the “find custom element” algorithm should be modified to walk the tree to find either a scoped registry or fall back to the global registry.

On the above, there was full agreement, which left three open questions remaining:

• How do Scoped Custom Element Registries interact with Declarative Shadow DOM (DSD)?
• How does element upgrade ordering work, particularly in scenarios with multiple documents?
• What happens when elements with different registries are moved between shadow roots and documents?

Consensus was quickly reached on DSD/Scoped Registry integration, allowing a DSD attribute to indicate that it would have a custom registry assigned later, and to delay element upgrade until that time. Thanks to the presence of a Microsoft employee who was already prototyping Scoped Custom Element Registries in Chromium, the remaining technical questions were able to be addressed, with the following resolutions:

• Resolution: Use an ordered set of weak references to documents to which the shadow root was created with the given custom element registry. When a shadow root is adopted from one document to another, the document should be inserted into the ordered set. Ignore any documents without a browsing context at the time of the upgrade call. In each document, all shadow trees should be visited in the document order.
• Resolution: When calling customElements.upgrade(...), upgrade all elements, including their shadow roots, which may have different registries. The global registry will be the only place where the upgrade() API exists, in order to make this clear.

The consensus and resolutions arrived at during this session were a huge success of this year’s TPAC, allowing the proposal to move forward. Just last week, a PR was put up for Chromium with an implementation based on the above resolutions.

Session: DOM/Template Parts API

DOM Parts is a new API designed to be used by templating and SSR engines. It enables marking locations within a DOM tree so that performant, dynamic data updates can be made at those places. The API helps remove the need to parse templates and eliminates the typical DOM tree walks that are needed by rendering engines either to instantiate data-bound templates or hydrate previously SSR’d HTML.

There was strong consensus on using {{}} for the basic syntax and {{#}}...{{/}} for ranges/blocks along with an opt-in attribute, such as parseparts , which would be placed on HTML elements where the author wants this syntax to be recognized and handled by the browser.

There was also strong interest in this API, especially from Google and Apple. During the meeting, Google shared that they had already landed the first patch of their prototype in Chromium and that they are testing internally with their frameworks to understand performance improvements. Interested library and framework authors can try this out today through Chrome’s experimental web platform features support (just remember that it is very, very early).

Session: Alternative to customized built-ins

There are two types of custom elements: autonomous custom elements and customizable built-ins. Autonomous custom elements inherit from HTMLElement and don’t come with any built-in semantics or behavior beyond the base. On the other hand, customizable built-ins inherit from more specific types, such as HTMLButtonElement, which bring all their functionality along.

Historically, WebKit never agreed to customizable built-ins. They had a number of objections to the proposal, as have various members of the community. For quite some time, there was no progress on this, but recently the conversation has been restarted, with the goal of working on an alternative standard that would enable the original scenarios of customizable built-ins while avoiding the issues.

During the breakout session, there was discussion of the constraints that proposals would need to work within to find a solution that every browser vender would support. The key use cases were:

• Enable progressive enhancement.
• Enable adding new behavior to existing elements.
• Support special parsing scenarios, such as how HTML treats tables.
• The API must be polyfillable.

There was huge interest in this feature and general excitement by a number of attendees who have wanted something like this in HTML for a long time. Several different proposals were put forward, which already had quite a bit in common:

• They support composition over inheritance.
• They allow encapsulating re-usable behavior that can be attached to different kinds of elements.
• They support attaching multiple behaviors to the same element.

There was extended discussion on if and how to scope these behaviors/enhancements to specific elements. Many details of the various proposals still need to be worked out:

• How do you associate behavior with an element?
• How do you filter or validate the elements it can be applied to?
• What are the mechanics of how it’s applied to the instance?
• What about upgrades of attributes or custom elements underneath the behaviors?
• Should there be a separate registry, or should the custom element registry handle this as well?

There seemed to be consensus on using the custom elements registry for this new feature and that it would be good to reuse the same lifecycle as custom elements as well.

There was so much energy around this idea, that Lea Verou even put forward a new proposal before the end of the day.

Session: Cross ShadowRoot ARIA

To enable various accessibility scenarios, there is a need to link elements across Shadow DOM boundaries. Today, there is no way to do this, so developers working with Shadow DOM…well, let’s just say they have to get creative in a few specific cases.

There are a number of different proposals that have been put forth to address this feature gap. The key challenge has been in finding a single solution that can address all the scenarios, while also garnering support from all interested parties.

During the session, much of the time was spent discussing some of the complex challenges in the space, along with how the new Export Ids proposal would solve them. Lots of discussion covered topics of syntax as well as encapsulation. The overwhelming concerns around Export Ids were:

• It is quite complex compared to other proposals.
• It puts the burden on the user of the element rather than the implementor for many details.

Coming out of the breakout, there was a request to take Export Ids and try to harmonize it with the separate Semantic Delegates proposal. Semantic Delegates makes the most common scenarios easy, while Export Ids makes the most challenging scenarios possible. If these two could be worked through together, perhaps we could arrive at a unified solution with the best of both.

Wrapping Up

This year’s TPAC was a resounding success for Web Components, with key commitments from implementors and great forward movement on community-prioritized specs. With the renewal of face-to-face meetings between CG members and implementors and the focus on more structured meetings with concrete outcomes, the coming year looks bright for continued Web Component progress.

If you enjoyed the wrap-up of this year’s TPAC Web Component sessions, you might want to check out my Web Component Engineering course. I’d also love it if you would subscribe to this blog, subscribe to my YouTube channel, or follow me on twitter. Your support greatly helps me continue writing and bringing this kind of content to the broader community. Thank you!