- From: <bugzilla@jessica.w3.org>
- Date: Thu, 10 May 2012 00:08:17 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16176 --- Comment #10 from Dimitri Glazkov <dglazkov@chromium.org> 2012-05-10 00:08:17 UTC --- 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 00:08:20 UTC