- From: <bugzilla@jessica.w3.org>
- Date: Mon, 24 Mar 2014 04:50:29 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887 --- Comment #67 from Hayato Ito <hayato@chromium.org> --- Thank you for all guys for comments for the event path. I am feeling that I have to explain the background of the current event path calculation algorithms and the rationale of that. I've designed the current event path algorithms so that we can achieve the following goal: Objective A) In *each* node tree (forget other node trees), the event path should be a *linear* path. That means: - If a node on the event path has the parent node in the node tree, the parent node should also be on the event path. Only exception is the root node of a node tree. - In each node tree, the child node must come before its parent node on the event path. >From the view of developers whose concern is only one node tree where they live, they see the behavior of the event path doesn't change at all as long as their concern is one node tree. They shouldn't care of other node trees. The following is *not* the goal of the current algorithm: Objective B) Define a reasonable total *order* between nodes which are in different node trees on the same event path. I'd like to point out the following fact because I guess every one here doesn't notice this fact: - Think about a tree of trees. Node trees that are involved in one even path can *form* a tree of node trees. Node trees can't be linear here. I suggest you guys to think about this fact carefully. You can easily create this case by modifying the example in comment #50 as follows: - Make <div id=5> a shadow host and let it host the following shadow tree. <shadowroot id="11"> <div id="12"> <content id="13"></content> </div> </shadowroot> In this case: - Event path will be [3, 2, 7, 10, 9, 8, 6, 13, 12, 11, 5, 4, 1]. - There are 4 node trees which are involved in this event path. - A node tree whose root node is #4 have *two* child node trees, a node tree whose root node is #8 and a node tree whose root node is #11. It'd be difficult to define a reasonable total order between nodes in this case. Can you define a reasonable total order in this case? DFS pre-oder? BFS-post-order? Neither can be a reason strong enough to abandon the current simple *one-pass* algorithm. That's the reason why objective B) is not the goal. The current algorithm uses one-pass algorithm and can achieve the objective A) at the same time. I think simple one-pass algorithm is important here for the efficiency. I'm not saying that we should include insertion points in the event path. That's orthogonal. However, comment #63 can't be a strong reason not to include insertion points because the claim of 'union of two event paths is a tree' is not correct according to the current spec. The current spec doesn't define one *super* node tree, which are composed of nodes which participate in a node tree in the same tree of trees. The spec doesn't define ancestor/descendant relationships between nodes if they are in different node trees. That's intentional. That means a *tree* used in 'union of two event paths is a tree' can't have a clear definition. Nodes in different node trees can't be a tree. They live in separated worlds and should be considered as disconnected. One more thing: If we would exclude all insertion points from event path, we must have exceptional rule for insertion points which have fallback elements. Example: <shadowroot id="n1"> <div id="n2"> <content id="n3" select="#non-existent> // doesn't select nodes. In this case, a fallback element, "n4", is distributed to this. <div id="n4"> </div> </content> </div> </shadowroot> In this case, event path for "#n4" can't be [n4, n2, n1]. That should be [n4, n3, n2, n1]. We have to have an exceptional rule. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 24 March 2014 04:50:31 UTC