- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Wed, 09 Jul 2008 22:13:47 +0200
- To: Kartikaya Gupta <kagupta@rim.com>
- Cc: public-webapps <public-webapps@w3.org>
Apologies for not responding to this question sooner. Somehow it got
lost in my TODO pile.
Moved from public-webapi to public-webapps. Original message here.
http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0133.html
Kartikaya Gupta wrote:
>>From reading the spec, it wasn't immediately clear to me which of the
> following two cases applies to element.querySelectorAll (and similarly
> to element.querySelector):
>
> 1. The nodes returned are the nodes that match
> document.querySelectorAll AND are contained within the subtree rooted at
> the element.
> 2. The nodes returned are the nodes that match the group of
> selectors if the selection algorithm is run only on the subtree rooted
> at the element.
>
> <html>
> <body>
> <div id="foo">
> <a
> href="javascript:alert(document.getElementById('foo').querySelector('bod
> y a'));">test</a>
> </div>
> </body>
> </html>
>
> If case (1) applies, then the querySelector should match the anchor tag
> and the dialog should show [object HTMLAnchorElement]. If case (2)
> applies, then since there is no "body" tag within the <div id="foo">,
> nothing will match and the alert dialog will show null.
This issue was discussed significantly in other threads and as currently
specced, case (1) is the correct behaviour. The proposal to address the
problem of when case (2) is desired is expected to be solved with a new
selector that matches the element upon which the method was invoked.
If you wish to test out anything like this in the future, you can test
it in WebKit nightlies [1], or Opera's Acid3 WinGgogi or LinGogi builds [2].
[1] http://nightly.webkit.org/
[2] http://labs.opera.com/news/2008/03/28/
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Received on Wednesday, 9 July 2008 20:14:26 UTC