Web Components Technology Tree

[thescientist13]

Overview

Coming out of our recent TPAC 2022 report planning meetings was the topic once again of how to best evaluate and balance the prioritization of each of the specification that we are tracking. Or from a reporting perspective, how to identify the most critical specs by which to highlight at the forefront of our report for the benefit of implementors.

As with last year, we are very aware of personal bias influencing our results and so try to be as objective as possible when choosing which specifications to advocate for more vocally. The reality is that there are many specifications to choose from, all with their own nuances around outstanding discussion topics, implementor positions and capacity, and of course perceived impact and value to the (web) dev community.

I really like the idea of thinking of all these specifications as a tech tree, very much inspired by the one from the video game Civilization. Effectively, a tech tree is just a graph of skills, technologies, sciences, etc that all relate to each other, in a way to builds upon itself to allow user's to grow strong with the more tech they learn. Additionally, tech from other "ladders" can be combined to unlock even more capabilities within the game.

So much like in the game, what do you focus on at any given time? Or another way to put it is; how do you want to win the game?

Motivation

So why a tech tree? I think the underlying rumination within all these related discussions around this topic of prioritization can be summed up by a desire to be able to answer, what if...?

• What if we really wanted SSR capabilities as soon as possible?
• What if we could eliminate all critical styling pain points?
• What if vendors only wanted to work on xxxx?
• What if we could pick whatever we want?

While specs are what bring more capabilities to the browser, it's important to be able to roll those up to the high level workflows that developers experience everyday when working with Web Components. By attributing metadata to these specifications and establishing relationships of inter-dependency or relatedness, it can help us build up potential paths of development that best achieves a focused and concentrated effort for whatever the situation calls for.

With this tech tree, we can better map out what those experiences and themes are, what they could be, and what they need to get there. We can help shape the "curriculum(s)" that can take advantage of real time information to better map out multiple flows and paths through the tree, to best try and maximize the time and effort for all collaborators.

It could also be used as a reference when "snapping a line" each year for this WCCG Community Proposal for "versioning" of Web Components.

Specifications (Technologies)

For accuracy, this tree could cover as little or as much as we want, but for a frame of reference, this list is based on the specifications from the (tentative) WCCG 2022 TPAC report.

• Form-Associated Custom Elements
• Cross-root ARIA
• Constructable Stylesheets & adoptedStyleSheets
• CSS Module Scripts
• Scoped Element Registries
• Declarative Shadow DOM
• Composed Selection
• Declarative CSS Modules
• Children changed callback
• Open styling of shadow roots
• Declarative custom elements
• Themeing
• Styling children of slotted content
• Custom CSS State
• Imperative Slot Assignment
• CSS Properties and values inside shadow root
• Lazy custom element definitions
• DOM Parts
• HTML modules
• Custom Attributes

So putting them all together, it might start to look like this.

(full credit to @EisenbergEffect for the image and the ladder groupings below! 🙌 )

Ladders

From the above list, the following "ladders" have been identified.

• Encapsulation
• Packaging and Distribution
• Integration
• API
• Styling
• Rendering & Performance

Attributes (Metadata)

• Status (shipped, limited, no support, in progress, idea)
• Spec Link
• Position(s) Link(s)

Themes

• SSG / SSR
• Forms
• Accessibility

Thoughts

So while this tech tree alone isn't the answer per se, it can help us get the answers. It's a like a data set with concrete relationships, that we can model and run queries against. By attributing metadata to these specifications and establishing relationships of inter-dependency or relatedness, it can help us build up potential paths of development that best achieves a focused and concentrated effort.

---

So, keeping mind this is just a first draft, there are some more items I would like to refine as a group

1. Cross-reference report spec list against graphic
2. Get short descriptions for ladders
3. Confirm and get sort descriptions for themes
4. Other attributes / metadata for tracking?
5. Define themes and descriptions for themes as