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.