- From: <bugzilla@jessica.w3.org>
- Date: Fri, 14 Mar 2014 07:23:43 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24872 --- Comment #11 from Hayato Ito <hayato@chromium.org> --- Thank you for the comments. Let me share my experience in blink's implementation, hoping that would be helpful for us to address perf's concern. I am aware that this is just one example and the explanation doesn't apply to any implementation. However, I think it is very important for us to share our experience. The change here, adding pseudo-classes to the matching criteria, would not have any impact of timing of re-calculation of distribution in blink. If a node is inserted somewhere, the *dirty* flag is always set to *inclusive ancestor* nodes of the node, in a sense of tree of trees, and we will run distribution algorithm (*1) anyway later. All these things already need dynamic check. The change here had an impact only on the following process in the pool distribution algorithm (*2) in blink's implementation: > If NODE satisfies CONTENT's matching criteria: Here, blink did some efforts to share the common logic between (existing) CSS selectors and matching criteria uses in content insertion points. The big difference between them is that nodes in POOL doesn't have *physical* siblings relationships. We can't use normal node->nextSibling in a DOM tree here because nodes in POOL requires the different *virtual* sibling traversal strategy. To share the common selector matching long nicely here, we had to introduce DOMSiblingTraversalStragegy, which is an abstraction how we traverse node's siblings. We used a kind of C++ template technique here so that this doesn't any performance impact on normal CSS selector's matching, which uses *normal* sibling traversal. I am afraid that this is too implementation detail and might not be discussed in the spec bug, however, I am happy to provide any further information! As for the imperative API, let's discuss how imperative API should be in bug 18429. I'll join the discussion. I hope the discussion in bug 18429 would have a good impact. *1. http://w3c.github.io/webcomponents/spec/shadow/#distribution-algorithms *2. http://w3c.github.io/webcomponents/spec/shadow/#dfn-pool-population-algorithm -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 14 March 2014 07:23:44 UTC