The talk at contributor's meeting force us to realize that
the current shadow DOM implementation needs to be understandable and explainable rather than something black magic.
I talked Dimitri and made up an initial plan. I won't file bugs for each until we actually start working
since the list is more like rough thoughts than real bugs to fix.
Relatively Solid takes (will be attacked at first):
- Rename ShadowTree to something more mindful: ElementShadow?
- Simplify API surface on ShadowTree(will be renamed)
- This will take a few takes.
- Renaming objects around HTMLContentElement for picking more spec-like terms:
- HTMLContentSelection -> ShadowDistributedNode // This should be killed eventually.
- HTMLContentSelectionList -> ShadowDistributedNodeList
- HTMLContentSelector -> ShadowNodeDistributor
- Split node distribution out from the attachment/detachment.
- Encapsulate tree stack operations by introducing ShadowTreeStack over DoublyLinkedList.
- Eliminate "right children" names if there are any.
Rather rough ideas:
- Eliminate RefPtr from selection to kill potential cycle.
- Simplify NodeRenderingContext by ensuring that the node attachment to start from the Shadow host.
- We can employ global stack to pass around the "rendering context" of shadow dom then.
- Optimize memory usage.
- Reduce the number of NodeRareaData instances
- Eliminate extra pointers (including turning doubly-linked list to singly-linked).
- Kill HTMLContentSelection
Looks like all subbugs are closed. closing this - The summer has come.