- From: <bugzilla@jessica.w3.org>
- Date: Tue, 15 May 2012 04:03:56 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16176 Hayato Ito <hayato@chromium.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #22 from Hayato Ito <hayato@chromium.org> 2012-05-15 04:03:56 UTC --- 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. > 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? -- 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 04:03:59 UTC