Bug 85263 – [Meta][Shadow DOM] Early Summer Refactoring.

• Component: DOM
• Status: RESOLVED FIXED

[Hajime Morrita]

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

[Hajime Morrita]

Looks like all subbugs are closed. closing this - The summer has come.