[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

--- Comment #12 from Hayato Ito <hayato@chromium.org> 2012-05-10 05:57:06 UTC ---
I've read carefully your suggestion and now I think I understand your
suggestion.

The doc was out-of-date. So I've updated the following section in the doc to
reflect your suggestions: 

https://docs.google.com/a/google.com/document/d/1PY7KkTRI-doU9Hew3Mud9JBgjj5xtVqH8sY0Ui305nw/edit:

  - Example tree (I've added labels to ShadowRoots and InsertionPoints to the
picture)
  - Examples (I've added ShadowRoots and InsertionPoints in the tables)

Please take a look at examples and let me tell whether this reflects your
intention or not.

# I think we should paste the picture and tables from the doc here using
acsii-art or something for the record. But forgive my laziness...

(In reply to comment #11)
> (In reply to comment #10)
> 
> > 3) relativeTarget is a variable, as Hayato-san suspects. The general idea is
> > that we build a list of relative targets for each tree scope using adjusted
> > target algorithm, then supply the relatedTarget of the same scope as the
> > adjusted target. This is an easy map, constant time thing.
> 
> Correction: The general idea is that we build a list of adjusted relatedTargets
> for each scope...

(In reply to comment #10)
> I worked on this a bit today, using excellent examples in
> https://docs.google.com/a/google.com/document/d/1PY7KkTRI-doU9Hew3Mud9JBgjj5xtVqH8sY0Ui305nw/edit.
> Here are some findings:
> 
> 1) The calculations in the referenced doc do not take insertion points or
> shadow roots into the account. Nothing in spec says that we shouldn't fire
> event on insertion point or shadow roots. So, for D, the chain of ancestors
> will actually be:
> 
> A - B - [ ] - G - [ ] - J - <K> - <H> - C - D
> 
> where [ ] is a shadow root and <X> is an insertion point.
> 
> 2) The calculation of adjusted target is wrong. We should treat insertion
> points differently from the shadow roots. In fact, the whole notion of
> boundaries must be discarded and replaced instead with a stack. We always read
> the top of the stack as the relative target. When we begin, we push target node
> into the stack. When we encounter an insertion point as a parent, we push
> current target into the stack. When we pass a shadow root, we pop the stack. If
> there's nothing in stack, we immediately push shadow host into the stack.
> 
> This gives us a correct representation of the relative target. For example, for
> D, it will be:
> 
> D - D - H - H - K - K -K - H - D - D
> 
> 3) relativeTarget is a variable, as Hayato-san suspects. The general idea is
> that we build a list of relative targets for each tree scope using adjusted
> target algorithm, then supply the relatedTarget of the same scope as the
> adjusted target. This is an easy map, constant time thing.
> 
> I will try to write this down as spec tomorrow.

-- 
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 Thursday, 10 May 2012 05:57:10 UTC