Bug Tracker

Opened 12 years ago

Closed 12 years ago

#9391 closed feature (wontfix)

:depth() Selector

Reported by: [email protected] Owned by:
Priority: low Milestone: 1.7
Component: selector Version: 1.6.1
Keywords: 1.7-discuss Cc:
Blocked by: Blocking:

Description (last modified by scottgonzalez)

I'd like to see what I'd call a 'depth' selector or filter. This would let me find an element(s), matching a selector, that was specifically the nth nested level of that element down from the current location (in fact, it would be very handy to be able to traverse both up and down the DOM).

This would be useful when working with sites that output code that contains a great deal of nesting of divs, ULs or tables. As an example, here's something of the flavour of what I'm after:

$('table.someClass > td:depth(3)')

which would be easier than...

$('table.someClass > tbody > tr > td > table > tbody > tr > td > div > table > tbody > tr > td)')

If you wanted to select all TDs that were 3 levels down and any other descendant TDs, you would simply write:

$('table#someClass > td:depth(2) td')

I suppose the downside is that people might use it out of laziness when it may be far more optimal to write code that was just a little longer.

Thanks for reading.


Change History (16)

comment:1 Changed 12 years ago by john

Keywords: 1.7-discuss added

Nominating ticket for 1.7 discussion.

comment:2 Changed 12 years ago by Rick Waldron

Description: modified (diff)

-1, This needs education, not new features.

comment:3 in reply to:  2 Changed 12 years ago by [email protected]

Replying to rwaldron:

-1, This needs education, not new features.

Although my second example is silly – $('table#someClass > td:depth(2) td') – the first is not, as there's no simple means of stopping all descendant matching elements from being returned AFAIK. Another solution, then, could be:

$('td td td:stop')

Where :stop prevents the DOM being traversed to a greater depth than the initial level of matched elements.

comment:4 Changed 12 years ago by jaubourg

-1, depth is the worst info you could use to select in the DOM.

comment:5 Changed 12 years ago by timmywil


comment:6 Changed 12 years ago by Rick Waldron

Component: unfiledselector
Description: modified (diff)
Priority: undecidedlow

@rob, yes I understood that, but the proposal indicates a misunderstanding of how selectors work. The proposal seems to assume that selectors are evaluated from right-to-left, when they're actually evaluated left to right - which makes a huge difference in how your proposal is interpreted.

comment:7 Changed 12 years ago by [email protected]

Are you saying that there's no way to make this efficient, or that the idea is conceptually incorrect? (Genuinely curious).

comment:8 Changed 12 years ago by paul.irish

-1, the usecase for nested tables is clear, i agree.. one could also set a class on each of the tables and reduce the selector that way.

can't thing of strong use cases other than nested tables.. makes sense for an external plugin.

comment:9 Changed 12 years ago by anonymous

I'm working with a CMS where I have no access to the code that generates the source, unfortunately, so I can't add the class names or IDs I'd like.

comment:10 Changed 12 years ago by timmywil

Status: newopen

comment:11 Changed 12 years ago by dmethvin

-1, No new selectors

comment:12 Changed 12 years ago by john

Description: modified (diff)

-1, Plugin.

comment:13 Changed 12 years ago by addyosmani


comment:14 Changed 12 years ago by ajpiano

Description: modified (diff)

-1, This scares me

comment:15 Changed 12 years ago by scottgonzalez

Description: modified (diff)


comment:16 Changed 12 years ago by Rick Waldron

Milestone: 1.next1.7
Resolution: wontfix
Status: openclosed

Closing per 1.7 roadmap meeting resolution

Note: See TracTickets for help on using tickets.