- 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