[Bug 23887] [Shadow] Put only the final destination insertion point to the event path

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

--- Comment #90 from Boris Zbarsky <bzbarsky@mit.edu> ---
We put together an etherpad to look at some examples, at
https://etherpad.mozilla.org/RKukNtHHlO

I think my intuition, when formalized, would boil down to changing
http://w3c.github.io/webcomponents/spec/shadow/#event-paths to the following:

1. Let PATH be the empty ordered list of nodes
2. Let CURRENT be NODE
3. Add CURRENT to PATH
4. Set INSERTION_POINTS to be the destination insertion points of NODE.
5. If INSERTION_POINTS is not empty:
   1. Set INS to the last element of INSERTION_POINTS.
   2. Remove the last element from INSERTION_POINTS.
   3. Set CURRENT to INS.
   4. Add CURRENT to PATH.
4. Repeat while CURRENT exists:
   1. If CURRENT is a shadow root:
      1. If NODE and CURRENT are in the same node tree and EVENT is one of the
         events which must be stopped:
         1. Stop this algorithm
      2. If INSERTION_POINTS is not empty:
         1. Set INS to the last element of INSERTION_POINTS.
         2. While INS is a shadow insertion point:
            1. Remove the last element from INSERTION_POINTS.
            2. Add INS to PATH.
            3. Add the older shadow root relative to the root node of INS to
               PATH.
         3. Remove the last element from INSERTION_POINTS.
         4. Add INS to PATH.
      3. Let CURRENT be the shadow host which hosts CURRENT
         1. Add CURRENT to PATH
   2. Otherwise:
      1. Let CURRENT be the parent node of CURRENT
      2. If CURRENT exists:
         1. Add CURRENT to PATH

Take the shadow insertion point bit with a grain of salt.  For example, I don't
understand why the spec has the "If SHADOW-ROOT is not the oldest shadow root"
clause: it seems like if "destination insertion points" contains a shadow
insertion point that means ipso facto that its root was not the oldest shadow
root....  In any case, I modeled this above as basically the newer shadow tree
being applied to the old shadow root, with distribution happening into shadow
insertion points instead of normal insertion points.  Hopefully that
understanding of how multiple shadow trees and shadow insertion points work is
correct.

Basically, the upshot is that insertion points here are kept with their parent
in the dispatch path as opposed to being kept with their distributed nodes.

It's not obvious that this is any simpler spec-wise than what's in the spec
right now (and in fact it looks a bit more complicated, though mostly because
of the shadow handling).  What do people think of the effects on the mental
model for consumers of shadow DOM, though?

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

Received on Friday, 28 March 2014 20:37:19 UTC