Preparing for "Web Components Community Group: 2022 Spec/API status"

[Westbrook]

I'll break out separate threads below for each of the topics available in our 2021 report so we can gather updates on status and outline what we might want to say about those APIs this year.

If you've got APIs that we chose not to include (even if just for time), please open a new discussion thread below so we can get an idea of what coverage we'd like to make for this years report.

We'll also be gathering for TBD life sessions to discussion these on a weekly or bi-weekly basis leading up to TPAC. Share you availability here if you'd like to join, and checkout our Slack channel to ensure you're included in invites, etc.

[Westbrook]

Form Associated Custom Elements

[calebdwilliams]

A lot of really good momentum here. Chrome has had form-associated custom elements turned on for awhile now, but as of around version 100, Firefox has enabled the full ElementInternals spec (minus CustomStateSet) which comprises the form-associated custom elements features. Safari still doesn't have the feature enabled (but it can be polyfilled), but there does appear to be active work on adding ElementInternals to WebKit.

There are a few small questions where the spec hasn't been implemented entire, specifically in relation to formStateRestoreCallback which should support autocomplete features, but it's not clear from the spec how exactly that feature should be triggered and based on the source for Chrome and Firefox, neither browser has implemented the feature.

[claviska]

A WebKit PR for this is located here: WebKit/WebKit#2690

[thescientist13]

For those following along, this was added to our report #42 🙌

[Westbrook]

Cross Root Aria

[Westbrook]

Some great progress has come together on Attribute Delegation via: https://github.com/leobalter/cross-root-aria-delegation and its corollary Attribute Reflection (name is a work in progress) via: https://github.com/Westbrook/cross-root-aria-reflection. The earlier has pretty solid agreement from browsers and is looking like it's a spec text approval away from beginning to gather implementors. The later is newer, but based off of similar ideas and holding similar excitement, if not yet agreement, from vendors.

Together, they beg a question as to whether this should be an "Aria" spec or an "Attribute" spec, so that we can easily pass references for concepts including those outlined by the Popup API and CSS Anchor Positioning.

[Westbrook]

If you have thoughts on the growing explainer for Aria Attribute Reflection, would love to see issues or questions here so we can continue to flesh it and the related Aria Attribute Delegation proposals out for implementors.

[Westbrook]

Include Element references in this convo.

[thescientist13]

For those following along, PR us up #46 🙌

[Westbrook]

Constructible Style Sheets & adoptedStyleSheets

[Westbrook]

Firefox shipped both of these in v101 this year. This leaves only Safari missing an implementation.

[Westbrook]

No longer frozen array.

[thescientist13]

Added an issue to the Webkit Standards Position repo

edit:

got some feedback comments there already that I'm not super familiar with, but will brush up on those referenced issues and see if I can comment back.

[thescientist13]

PR is up for those following along #50 🙌

[Westbrook]

CSS Module Scripts

[Westbrook]

Should we push on this as "Import Assertions", generally, or is there a benefit to focus specifically on CSS at this point?

[calebdwilliams]

This depends at least in part on constructible stylesheets, so that should take precedence. I think that pushing on import assertions generally would do us well here especially because CSS modules are likely a fast-follow to that and will depend on it.

This will likely also have an effect on a lot of the tools developers use day-to-day (TypeScript supports the syntax, Rollup does too with the right Acorn plugins, Webpack isn't super happy about it, I don't know about others), so broadening the scope of the effort here will be worthwhile.

[Westbrook]

That's an interesting angle to take (in this report or another), the community's support for various APIs/spec via tooling.

When a polyfill is appropriate, it would probably be good to list it in the report, aligns closely to Web Platform Test that we might take some role in making sure exist and are referenced appropriately. When you actually have to process code for it to work, see assert then an apendix or related report might be my suggestion. Thoughts?

[calebdwilliams]

I think that makes sense.

Also, many of the technologies in this document are related at some level of scale. It might also do us well to map those relationships out explicitly.

[Westbrook]

Scoped Element Registries

[Westbrook]

@justinfagnani or @leobalter did push in this area from the team at Sales Force get us any closer to proposed spec text?

[justinfagnani]

Nothing yet, but hopefully

[Westbrook]

Is this the NUMBER 1 priority now that other things have started to ship a little?

How can the DSD interaction that Safari is worried about be clarified?

[Westbrook]

Let's open PRs for all the issues so we can move this forward!

[thescientist13]

PR open / merged for anyone following along - #51 🙌

[Westbrook]

Declarative Shadow DOM

[mfreed7]

@koddsson I'm excited to hear GitHub is interested in DSD! That would likely help convince the other implementers of the value of the feature overall, especially if any public performance data comes out of that effort. Let me know if I can help in any way.

Side note: I've worked with a few internal partners who were planning to just not ship a polyfill with their SSR content. In that case, the <template shadowroot=open> element falls back to an inert <template> on unsupported rendering engines, and the page waits for JS to hydrate the shadow roots when they load, as they do today. Perhaps that's an option?

[koddsson]

@koddsson how does GH handle no JS today? Should the community be looking into hybrid solutions where there's a DSD fallback from JS and a no-DSD fallback from there? In most of the apps I work on you have to have JS at some point and it would be a loading process benefit. However, in a form processable application like GH a.

The unofficial stance is to try to make as much as possible of the site work in "read-only" mode when JS doesn't load. That's more of guidance, so some teams write entirely JS-rendered experiences. I think we can start experimenting with DSD rendering in those places.

@koddsson I'm excited to hear GitHub is interested in DSD! That would likely help convince the other implementers of the value of the feature overall, especially if any public performance data comes out of that effort. Let me know if I can help in any way.

I'll brainstorm on this a bit. We've been cautious about implementing just the Shadow DOM to make sure we aren't breaking things for some users, but recently we shipped Shadow DOM in <image-crop> and <include-fragment>. Maybe we should start looking at places where we can test out DSD. cc/ @keithamus

What should we be looking out for in terms of performance? Maybe I can start monitoring this week, so we have some data to compare to when we ship DSD.

[keithamus]

The hesitancy for us right now is lack of strong positive signals from Mozilla or Apple.

The performance of ShadowDOM in my opinion is an overall less interesting story than the architectural benefits. One of the big issues we face with our design system today is encapsulated CSS, which ShadowDOM effortlessly fixes, along with other ergonomic improvements such as less complex class names, and flexibility around CSS variables penetrating shadow roots, light dom styles etc.

I'm confident that if we migrated our components entirely to using ShadowDOM we could improve LCP overall as one of the biggest costs to our LCP is the CSS bundles we have. DSD takes that up a notch as we're able to move reification of shadowroots before DOMContentLoaded, but largely it feels like we'd gain the most performance from componentising our CSS using ShadowDOM. The concern around just using ShadowDOM is the lack of resiliency: without JS the site fails to do anything useful, and that to us is a threshold we're not prepared to cross in the general case. As @koddsson points out we have a concept of "read only" mode, where we expect a baseline experience to exist without JS. Therefore without a clear path to having DSD implemented in all browsers, where we can move wholesale to reap the rewards, we're stuck in a state where some (Firefox & Safari) users will get a slower and less resilient experience, for the benefit of (currently) Chrome & Edge users.

We also need to think about the long tail of users on older browsers, where DSD much less ShadowDOM doesn't exist, however can be solved by simply waiting. Performance issues aside, we're happy enough with the current state of DSD polyfills, but ShadowDOM polyfills (like ShadyDOM) cause severe performance degradation on the site. Up until very recently we've still had a core contingent of browsers that do not support ShadowDOM which has been a blocker, but that's being lifted.

With regards to Scoped Element Registries - this isn't a concern for us. Our highest priority would be DSD across all browsers.

[mfreed7]

@keithamus thanks for the detailed explanation about GitHub's motivation for shadow DOM and DSD! This would be a very helpful comment to add on whatwg/dom#831, as it goes to the need for the feature, independent of performance concerns.

[thescientist13]

Opened a PR to get this added to our report - #45.

[Westbrook]

Composed Selection

[hunterloftis]

• @mfreed7 has been driving progress since last year
• TAG concluded design review & approves
• I'm not aware of any remaining objections / use-cases that are not possible with the current proposed design of getComposedRange()
  • Although only one of the major rich text editors from our report has responded:
    • TinyMCE
    • CKEditor: crickets
    • Quill: crickets
• I'm not aware of any movement of browser implementations (other places to check? If not, where to nudge?)
  • 5-year old Mozilla issue
  • 6-year old Webkit issue
• I think that the current Status should be updated to:
  • General consensus, no implementation of the agreed-upon design, divergent implementations of the previous selection API

[Westbrook]

Declarative CSS Modules

[calebdwilliams]

Calling out for the sake of completeness, this depends in part on constructible stylesheets (or DocumentOrShadowRoot.prototype.adoptedStyleSheets), CSS module scripts and likely import assertions.

[hsablonniere]

This one is very important 🙏
Without this, Declarative Shadow DOM feels a bit half baked as for each instance of a component, we need to repeat the same CSS in the rendered output.
Combined with CSS Module Scripts, this would be a nice standard way to render web components from a server.

[nolanlawson]

You can use a <link rel=stylesheet> to avoid some repetition (vs <style>), but yeah, it's not ideal.

For us (LWC), it's a bit awkward to have constructable stylesheets rendered on the client but <style>s/<link>s in SSR.

[sashafirsov]

Seems like the need to share styles across subset of components is a must requirement for WS library. Tried to emphasize the importance of namespace scope in #scoping-wc channel. Such namespacing is needed not just for CSS but also for scoped registry, module loader, etc.

[Westbrook]

Children changed callback

[Westbrook]

Might interact with Imperative Slotting?

Might interact with WICG/webcomponents#933

[alangdm]

I tried gathering the info for this, there wasn't much consensus on anything but hopefully it helps to show the current situation:

Children Changed Calback

Children Changed Callback

Description

Provide a callback that triggers whenever the parser finishes parsing children or when a new child is inserted or an old child is removed.

Links

• Discussions:
  • 2019 discussion - open
  • December 2016 discussion - closed
  • August 2016 discussion regarding parsing timing - closed
  • August 2016 discussion - closed
• Polyfills/Libraries:
  • For the parsing behavior

Status

• No concrete proposal / no consensus on spec

Initial API Summary/Quick API Proposal

class ChildrenChangedCallbackSample extends HTMLElement {
  // couldn't find any reference to any proposed function signature
  childrenChangedCallback() {}
}

Key Scenarios

• Children parsed: This proposal would act as a cross-browser method of detecting when a custom element's children have been fully parsed reliably.
• Children inserted/removed: This proposal would provide better ergonomics to react to insertion or removal of children nodes than using a MutationObserver.

Concerns

1. Too expensive to implement - no longer the case, all engines have mechanisms for this already
2. The addition of the parsing behavior might encourage assuming a set of initial children exists and not reacting to changes in them.

Dissenting Opinion

1. Some people believe using a MutationObserver is enough to cover the insertion/removal cases and want to avoid creating a duplicate similar API for custom elements. But the async nature of MutationObserver seems to cause timing issues.
2. Some other people don't want to add this API if it will only cover the use case when the parser finishes parsing children. (See concern 2)

Related Specs

• slotchange event options

Open Questions

• Should this API really cover both use cases to begin with? (Arguments for both sides have been mentioned in all referenced discussions with no conclusion)
• Should this be one or two separate callback functions?
• Would it be better to implement this behavior as part of slotchange as suggested in this other issue? - this might lead to engine security bugs so the callback might be preferred

[alangdm]

I created a PR for this so we can do the review process there #40

[thescientist13]

For those following along, this was added to our report #40 🙌

[Westbrook]

Open styling of shadow roots

[Westbrook]

Understand and preparation for this situation may benefit from Devographics/surveys#19?

[Westbrook]

Does this conversation benefit from pairing with the @scope specification work?

[Westbrook]

heard this being proposed when developers want to continue to use global styles (like typography styles) across document and multiple shadow roots.

[davatron5000]

FWIW, I was just asked today "How do you handle shared styles?" by someone getting into web components. The styling story here isn't great.

[thescientist13]

Might be worth getting feedback and anecdotes captured in this docs + guides repo - webcomponents-cg/docs-and-guides#21? Or capture somewhere for sure but I agree there is a lot of opportunity in knowledge sharing / documenting around CSS and WCs, especially since CSS is global by default and so that (naturally) dominates the implementation assumptions of the CSS ecosystem at large.

IMO, it would really be great to have a dedicated guide on styling WCs, either globally and / or with (Declarative) Shadow DOM.

[Westbrook]

Declarative custom elements

[sashafirsov]

The declarative custom element would need dependencies management protocol. Which most likely would match the HTML module model.
@thescientist13 , if this protocol a part of HTML module concept, should we describe it in a separate proposal?

[sashafirsov]

Created #32 to discuss and track it further

[thescientist13]

For those following along, this was added to our report #41 🙌

[Westbrook]

Themeing (::theme)

GitHub Issues: WICG/webcomponents#864

[alangdm]

I'm working on this

[thescientist13]

Woo hoo, PR is up and ready for review - #54 🙌

[Westbrook]

Styling children of slotted content

refs #5

[Westbrook]

Custom CSS State

GitHub Issues: WICG/webcomponents#738

[Westbrook]

Container Style Queries seem to be giving the capabilities here a run for their money... https://una.im/style-queries/#4-grouping-styles-with-higher-order-variables

[thescientist13]

PR for this is up - #56 ! 🙌

[Westbrook]

Imperative Slot Assignment

re: whatwg/html#3534

[thescientist13]

@Westbrook
Not sure if I am reading this right but for Safari, I do see an item for Imperative Slot API that links to this DOM spec in their feature tracker, which seems to be the same thing being discussed in whatwg/html#3534?

Or is there a nuance I'm missing around this spec? Here is what I have so far

• Chrome - https://chromestatus.com/feature/5711021289242624
• Firefox - Imperative Shadow DOM Distribution API mozilla/standards-positions#409
• Safari - https://webkit.org/status/#feature-imperative-slot-api

[Westbrook]

I’m pretty sure they recently “finished it”, but it’s unclear whether they’ve “shipped it”, past I checked.

[Westbrook]

For instance this doesn’t work in iOS, but might work in desktop/tech preview: https://codepen.io/Westbrook/pen/GRvbWzM

[thescientist13]

Ah I see. gotcha. That helps, as I wasn't sure how to frame the details in regards to the report, but should be able to make a go of it now.

[thescientist13]

For those following along, PR is up - #55! 🙌

[Westbrook]

CSS Properties and values inside shadow root

re: https://bugs.chromium.org/p/chromium/issues/detail?id=1231135

[Westbrook]

Lazy custom element definitions

GitHub Issues: WICG/webcomponents#782

[thescientist13]

For those following along, this was added to our report #41 🙌

[Westbrook]

DOM Parts (formerly Template Instantiation)

GitHub Issues: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts.md

[sashafirsov]

Added as todo item to implement in css-chain and derived shadow-dom-element and light-dom-element ( kind of declarative custom element polyfills ). Participation on browser Chromium/Blink and FF level is problematic due to time resources limits.

[sashafirsov]

Need someone to hand off or pair on this proposal status.

[thescientist13]

For those following along, this was added to our report #41 🙌

[Westbrook]

HTML modules

GitHub Issues: WICG/webcomponents#645

[Westbrook]

Without Constructible Style Sheets you can't have CSS Module Scripts, you import something that you assert to be CSS and you get a Constructible Style Sheet. This might not be "HTML Module", but what is we could assert that the thing we were importing was a custom element or "web component" and the thing we got was an element definition in its own module scope? In that way, all of the the custom elements defined within that scope could be encapsulated from the rest of the document, giving us an alternative path to Scoped Custom Elements.

It does sort of imply that if you delivered DSD into a custom element that you want to import as a Custom Element Module later we'd need to work out upgrading the shadow DOM to that scope. This seems like something you'd need either way. Either upgrading to include a new scope or adding to the DSD spec to register a scope and then be able to acquire the scope from the shadow root at a later time. This may be specifically the question at hand for Safari in regard to DSD and Scoped Registries, so it'll be interesting to see how that conversation goes.

[thescientist13]

PR for HTML Modules in the 2022 report is up - #60!

[Westbrook]

Native Behavior Mixins

link to conversation?

[Westbrook]

Some conversations around alternatives to customized built-ins point to the need for behavior mixins. Thinks like the for functionality in a <label> or showModal() functionality in a <dialog> or the behavior attribute in the <selectmenu> spec…

[LeaVerou]

This is actually useful for regular web components as well. Often a component is twopart: One or more new elements plus attributes to augment existing elements. Think of <datalist> and the <input list> attribute.
Relevant: whatwg/html#2271
It would be good to have an API for easily registering custom attributes (and maybe synced properties?) for other elements with code to react to changes (yes, we can do that with a Mutation Observer that listens to the entire document subtree, but maybe there's a better way).

[calebdwilliams]

MutationObserver is less than ideal because you'd also have to watch all shadow trees which is less than ideal. Curious if custom attributes would also need to be scoped like custom element registries.

[calebdwilliams]

It would be worthwhile to identify a list of built-in features we'd like to be able to add to the custom elements spec. Creating labelable elements is a great example. Creating a form-associated element (with or without attaching an internals instance) allows an element to accept a label, so

<script>
customElements.define('x-', class X extends HTMLElement {
  static formAssociated = true;
});
</script>
<form>
  <label for="x">This works via the AOM</label>
  <x- id="x"></x->
</form>

will create a labelable element, but that element does show up in HTMLFormElement.prototype.elements collection which is not always what a user will want when creating a loader, for one example.

It could be that just adding additional static props would be sufficient for many of these approaches.

[Westbrook]

The attribute relationship here plays a role in the Aria delegate/reflect APIs that may appease some of the use case there. However, the delegation approach there assumes the presence of a <label> element to complete the contract. I'm interested in what it would mean to make an <x-label> element that never relied on a native <label> element to fulfill the responsibilities that it needs to fill. So, instead of class XLabel extends HTMLLabelElement {} you could do something like class XLabel extends WithForAttribute(HTMLElement) {} or something like:

class XLabel extends HTMLElement {
  constructor() {
    super();
    this.#internals = this.attachInternals();
    this.#internals.mixins = [ withForElement, ... ];
}

Or something else along those lines.

[mfreed7]

I'll break out separate threads below for each of the topics available in our 2021 report so we can gather updates on status and outline what we might want to say about those APIs this year.

@Westbrook I've got a meta-question about the 2022 report. The "2021 version" is located at a base URL (https://w3c.github.io/webcomponents-cg/) that doesn't have "2021" in the name, and it has been updated as of 4 days ago (18 August 2022). Is there a plan to keep static annual reports ("2021", "2022", etc.) or is the plan to have a living document that is continuously updated? I'd vote for the former (distinct annual reports), since it gives us (implementers) a stake in the ground and allows us to reference changes over time as we implement things. The living document approach can also be useful, if you'd prefer to go that route. But in that case, could you please change the name accordingly? E.g. "Web Components Community Group: Evergreen Spec/API status" or something better.

Side note, which I've said multiple times: this effort to organize and prioritize outstanding Web Components issues is amazingly useful! Thank you all for putting in the effort!

[Westbrook]

@mfreed7 this is a great question and while we do have plans for yearly reports there definitely seems to be some planning missing in said plan. I've just been using the rSpec tooling from w3c without much thought as to when it says things have "updated" or not, see what I get for just assuming 🙈. The 2021 report hasn't technically updated since our presentation last year, except to get extra Mozilla position links and get moved to 2021.html in our repo 14 days ago: https://github.com/w3c/webcomponents-cg/commits/main/reports/status.html I'm not sure how to keep the project from continuing to say that it's updated on running publication of the 2022 work in progress report, but I'll see what I can do there.

I'm glad to hear that the "a stake in the ground" approach is useful to you as an implementor, as we as consuming developers are interested in making a more declarative stance around that "stake", but it's still in development. The idea of a Web Components 2022 to stand next to an es2022 feels pretty nice, and kicking of a conversation with implementors around how we could make that productive for everyone would be very nice!

[mfreed7]

@mfreed7 this is a great question and while we do have plans for yearly reports there definitely seems to be some planning missing in said plan. I've just been using the rSpec tooling from w3c without much thought as to when it says things have "updated" or not, see what I get for just assuming 🙈. The 2021 report hasn't technically updated since our presentation last year, except to get extra Mozilla position links and get moved to 2021.html in our repo 14 days ago: https://github.com/w3c/webcomponents-cg/commits/main/reports/status.html I'm not sure how to keep the project from continuing to say that it's updated on running publication of the 2022 work in progress report, but I'll see what I can do there.

Thanks, but I don't think that needs heroics. As long as the title and the content are actually per-year, I think that's great.

I'm glad to hear that the "a stake in the ground" approach is useful to you as an implementor, as we as consuming developers are interested in making a more declarative stance around that "stake", but it's still in development. The idea of a Web Components 2022 to stand next to an es2022 feels pretty nice, and kicking of a conversation with implementors around how we could make that productive for everyone would be very nice!

Cool, thanks! This is indeed useful to us.

[thescientist13]

For all those following along, our report will be presented this Wednesday, Sept. 14th @ 4:30 PST
https://www.w3.org/events/meetings/2f1bb21d-1d51-4528-9729-9da2bc611176

[Westbrook]

Time to get ready for 2023, closing. Thanks for all the discussion, I hope you'll all join us in preparation for this year's report.