Request for ">" selector to work in wider range of circumstances

Reported by:	wheresrhys@gmail.com	Owned by:
Priority:	low	Milestone:	1.next
Component:	selector	Version:	1.5.1
Keywords:	neededdocs	Cc:	john, jeresig
Blocked by:		Blocking:

Description

According to the specification > is only defined where parent and child are specified, 'parent > child', which arguably makes sense when used as an initial selector to set up a new jQuery object (although you coud also argue that "> child" could refer to children of body).

But where a context is specified e.g (">p", context), the selector is still valid (even though this isn't documented).

However, in other "contexty" contexts, using > without a parent does not work

e.g.

$(el).closest(">li", context)
$(context).delegate(">li", ...)

This

a) makes for an inconsistent and confusing api
b) limits/complicates the use of some otherwise straightforward and very useful jQuery methods

So I reckon jQuery should try and make > more widely applicable and, as a stopgap, at least update the documentation to clarify where > can and cannot be used

test page - http://jsfiddle.net/DMVDS/1/

Attachments (0)

Change History (5)

Changed March 30, 2011 06:46PM UTC by john comment:1

component:	unfiled → selector
keywords:	→ needsdocs
priority:	undecided → low
status:	new → open
type:	enhancement → bug

So yeah, we're not looking at add in new selectors that are invalid CSS selectors - and actually we're looking to deprecate $(">p", context). We'll look to document this.

Changed March 30, 2011 10:06PM UTC by wheresrhys comment:2

_comment0:	Replying to [comment:1 john]: \ > So yeah, we're not looking at add in new selectors that are invalid CSS selectors - and actually we're looking to deprecate $(">p", context). We'll look to document this. \ \ On the other hand there's a selector to match most (?all) of jQuery's DOM traversal methods, and not allowing ">p" means there is no equivalent for .children("p"), which isn't so much an argument for keeping the selector, but it does provide some rationale for not deprecating what is (or would be if it always worked) a very useful selector \ \ e.g in an accordion plugin you could use \ $(".myAccordion").delegate(">li", "click" , toggle) \ Without it the plugin would have to add a class to each child li to allow for the possibility of nested lists. \ \ And while the parent isn't explicitly defined in the selector, it is very strongly implicit when you consider the DOM nodes in the jQuery object to be the parents, so while not strictly speaking valid CSS, it's far from bing CSS nonsense → 1301933547019301
_comment1:	Replying to [comment:1 john]: \ > So yeah, we're not looking at add in new selectors that are invalid CSS selectors - and actually we're looking to deprecate $(">p", context). We'll look to document this. \ \ On the other hand there's a selector to match most (?all) of jQuery's DOM traversal methods, and not allowing ">p" means there is no equivalent for .children("p"), which isn't so much an argument for keeping the selector, but it does provide some rationale for not deprecating what is (or would be if it always worked) a very useful selector \ \ e.g in an accordion plugin you could use \ $(".myAccordion").delegate(">li", "click" , toggle) \ Without it the plugin would have to add a class to each child li to allow for the possibility of nested lists. (I just noticed it's used as a selector in jquery.ui http://jqueryui.com/demos/accordion/) \ \ And while the parent isn't explicitly defined in the selector, it is very strongly implicit when you consider the DOM nodes in the jQuery object to be the parents, so while not strictly speaking valid CSS, it's far from bing CSS nonsense → 1301991610210914

_comment0:

Replying to [comment:1 john]: \ > So yeah, we're not looking at add in new selectors that are invalid CSS selectors - and actually we're looking to deprecate $(">p", context). We'll look to document this. \ \ On the other hand there's a selector to match most (?all) of jQuery's DOM traversal methods, and not allowing ">p" means there is no equivalent for .children("p"), which isn't so much an argument for keeping the selector, but it does provide some rationale for not deprecating what is (or would be if it always worked) a very useful selector \ \ e.g in an accordion plugin you could use \ $(".myAccordion").delegate(">li", "click" , toggle) \ Without it the plugin would have to add a class to each child li to allow for the possibility of nested lists. \ \ And while the parent isn't explicitly defined in the selector, it is very strongly implicit when you consider the DOM nodes in the jQuery object to be the parents, so while not strictly speaking valid CSS, it's far from bing CSS nonsense → 1301933547019301

_comment1:

Replying to [comment:1 john]: \ > So yeah, we're not looking at add in new selectors that are invalid CSS selectors - and actually we're looking to deprecate $(">p", context). We'll look to document this. \ \ On the other hand there's a selector to match most (?all) of jQuery's DOM traversal methods, and not allowing ">p" means there is no equivalent for .children("p"), which isn't so much an argument for keeping the selector, but it does provide some rationale for not deprecating what is (or would be if it always worked) a very useful selector \ \ e.g in an accordion plugin you could use \ $(".myAccordion").delegate(">li", "click" , toggle) \ Without it the plugin would have to add a class to each child li to allow for the possibility of nested lists. (I just noticed it's used as a selector in jquery.ui http://jqueryui.com/demos/accordion/) \ \ And while the parent isn't explicitly defined in the selector, it is very strongly implicit when you consider the DOM nodes in the jQuery object to be the parents, so while not strictly speaking valid CSS, it's far from bing CSS nonsense → 1301991610210914

Replying to [comment:1 john]:

So yeah, we're not looking at add in new selectors that are invalid CSS selectors - and actually we're looking to deprecate $(">p", context). We'll look to document this.

On the other hand there's a selector to match most (?all) of jQuery's DOM traversal methods, and not allowing ">p" means there is no equivalent for .children("p"), which isn't so much an argument for keeping the selector, but it does provide some rationale for not deprecating what is (or would be if it always worked) a very useful selector

e.g in an accordion plugin you could use

$(".myAccordion").delegate(">li", "click" , toggle)

Without it the plugin would have to add a class to each child li to allow for the possibility of nested lists. (I just noticed it's used as a selector in jquery.ui http://jqueryui.com/demos/accordion/)

And while the parent isn't explicitly defined in the selector, it is very strongly implied when you consider the DOM nodes in the jQuery object to be the parents, so while not strictly speaking valid CSS, it's far from being CSS nonsense

Changed July 07, 2011 04:59AM UTC by addyosmani comment:3

cc:	→ john, jeresig

@john: With respect to your comments above, is the plan to deprecate $(">p", context) in 1.7 or one of the other upcoming future releases?

I ask as because we haven't yet defined a set action to along with this ticket it's hard to know whether any docs can be structured around this.

Would 'Note: $(">elem", context) may be deprecated in a future release and we discourage it's usage in lieu of alternative selectors at this time', suffice for now?

Changed July 12, 2011 04:40PM UTC by john comment:4

resolution:	→ wontfix
status:	open → closed

Replying to [comment:3 addyosmani]:

Yep, that sounds fine to me!

Changed July 14, 2011 01:38PM UTC by addyosmani comment:5

keywords:	needsdocs → neededdocs

Docs updated. http://api.jquery.com/child-selector/

Side navigation

#8384 closed bug (wontfix)