[Bug 22344] [Shadow]: Distribute into <shadow>, project into older shadow root

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22344

--- Comment #17 from Hayato Ito <hayato@chromium.org> ---
I've updated my WIP spec so that it supports the proposal.

https://docs.google.com/document/d/1iuf2DgzwKfMTscAX_xsymO73NmZ4NVYvfyFgUU4YINo/edit?usp=sharing


(In reply to comment #14)
> I'm not super comfortable having distribution not run in document order.
> Right now it's forced into O(n) behavior because you start at the top and
> spread things down. I don't want us to get into situations where you can
> generate non linear behavior (or need to use tons of memory to avoid doing
> so).


We can do in O(n).

Let me quote DISTRIBUTE_POOL algorithm here from the doc.

-- From HERE ---
DISTRIBUTE_POOL(SHADOW_ROOT, POOL) :=
  for each active content element, CONTENT, in SHADOW_ROOT, in tree order:
    for each node, NODE, in POOL:
      if the NODE satisfies CONTENT’s matching criteria:
        DISTRIBUTE_NODE(NODE, CONTENT)
        remove NODE from the POOL
      if insertion-point-to-nodes[CONTENT] is empty:  // [Informative:
Fallback]
        for each node, CHILD, in children of CONTENT:
          DISTRIBUTE_NODE(CHILD, CONTENT)
--- END HERE ---


If we encounter an active shadow insertion point in the outer 'for' loop, just
remember the position of the active insertion point and skip the traversal of
subtree of the active shadow insertion point.
Afte the loop, we continue to distribute POOL to content elements in the
subtree of the active insertion point.
That should be done in O(n).


But, I don't like such a hidden rule in general.
> Provided that all of your <content> selectors outside <shadow> precede it, so they get distributed to first. 


My proposal is use 'defer' attribute in content element such as:

> <shadow><content defer></content></shadow>

Like <scrit src='..' defer> is evaluated later, distributing nodes for <content
defer> is deferred.
I prefer this explicit approach than an implicit hidden rule.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 19 June 2013 02:40:14 UTC