[Bug 16176] [Shadow]: What should we do if an event happens on light child which is distributed to a insertion point.

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

Dimitri Glazkov <dglazkov@chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #23 from Dimitri Glazkov <dglazkov@chromium.org> 2012-05-15 18:02:10 UTC ---
(In reply to comment #22)
> Thank you for updating the spec. Let me reopen again :)
> 
> (In reply to comment #20)
> > > 
> > > > 1. If there is a DOM node that is a member of CANDIDATES and is in the same subtree as TARGET, let ADJUSTED be this DOM node
> > > 
> > > There may be multiple candidates in the same subree. In such case, we should
> > > pick up "the lowest'"candidate from the candidates.
> > 
> > Ah. good point. I think I need to change the CANDIDATES collection algorithm to
> > only pick up unique items.
> 
> Unfortunately, we may still have multiple candidate nodes in the same tree as a
> result.
> That's because when we climbing up ancestors of relatedTarget, we may
> *re-visit* the same subtree which we already visit before.
> We can see the example in the example tree.
> https://www.w3.org/Bugs/Public/attachment.cgi?id=1131
> If an original relatedTarget is F, both B and F will be added to CANDIDATES.

Yes, we only need to keep the *lowest* node in the CANDIDATES. Because we are
traversing from the bottom, we need to only check whether a node from the
subtree already exists in CANDIDATES.

> 
> 
> > If ANCESTOR is not in the same subtree as LAST and ANCESTOR is not an insertion point:
> 
> Why do we exclude InserionPoints from candidates? InsertionPoints could be a
> relatedTarget, couldn't we?

You're right. My bad.

http://dvcs.w3.org/hg/webcomponents/rev/9f40fd372168 <-- hopefully sticks this
time :)

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 15 May 2012 18:02:18 UTC