You need to
before you can comment on or make changes to this bug.
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.