85263 2012-04-30 22:59:10 -0700 [Meta][Shadow DOM] Early Summer Refactoring. 2012-08-09 19:19:58 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 77608 79220 85265 85970 86064 86427 87216 87223 72352 1 morrita morrita dglazkov hayato shinyak tasak oldest_to_newest 613252 0 morrita 2012-04-30 22:59:10 -0700 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 692110 1 morrita 2012-08-09 19:19:58 -0700 Looks like all subbugs are closed. closing this - The summer has come.