#Shadow DOM Evolution Plan
Today, the specs (Shadow DOM and Shadow DOM Styling) describe a set of machinery that is complete and useful enough to build real things with.
There are many bits we still need to add and improve. The few directly in sight were outlined in the 2014 plan.
A more fuzzy problem is primitive archeology. Solving that has a two-fold benefit: we both a) better understand the movable pieces in the Shadow DOM machinery and interactions between them and b) possibly expose new primitives that are individually useful on their own.
If I were to break Shadow DOM up into movable pieces, I would identify these two foundational chunks:
-
The ShadowRoot, its API, root/host relationship and tree of trees. It's likely that there are more lower-level primitives here. How is it that this particular flavor of a DocumentFragment is rendered? Still need to understand what are these things and how they could be useful.
-
Insertion points, distributions and the composed tree concept. Constructing the composed tree (and thus distributions) is somewhere in the realm of building a box tree and style computation. That pie is so large, it's hard to tell where which side to start on chewing. However, if there was an insertion point primitive, it would clearly need a DOM API, so maybe that's a good place dig in.
Layered over the two big ones are:
- the associated combinators and selectors and cascading model.
- event dispatch (target and relatedTarget adjustment)
<content>and<shadow>elements and their APIs
The CSS'ey things are just opaque syntax extensions. But the events and especially the new HTML elements are the ones we definitely should take for platform layering test drive.
Perhaps this would be a good high-level objective that could serve as an indicator for solving the primitive archeology problem: make both HTML elements introduced by Shadow DOM implementable using custom elements and the newly discovered insertion points primitives.