Bug Tracker

Ticket #2851 (closed enhancement: fixed)

Opened 7 years ago

Last modified 4 years ago

filter and is should accept complex selectors

Reported by: scott.gonzalez Owned by: flesler
Priority: major Milestone: 1.3
Component: selector Version: 1.2.3
Keywords: Cc: scott.gonzalez, john
Blocking: Blocked by:

Description


Change History

comment:1 Changed 7 years ago by flesler

  • Owner set to flesler
  • Status changed from new to assigned

comment:2 Changed 6 years ago by joern

Related to #3137

comment:3 Changed 6 years ago by joern

Related/duplicate to/of #2266.

comment:4 Changed 6 years ago by d.wachss

Rather than adding complex selectors (which would require more sophisticated string parsing and likely slow down everything), why not be consistent with "not" and allow arrays? Something like:

selector.length && selector[selector.length - 1] !== undefined && !selector.nodeType &&

return this.filter(function(){

jQuery.inArray( this, selector )

})

Then you could do $('code').filter($('pre > code')) which might be slow itself but would not affect other uses of filter.

comment:5 Changed 6 years ago by d.wachss

Oops--WikiFormatting killed my code. Supposed to be:

  !|| selector.length && selector[selector.length - 1] !== undefined && !selector.nodeType &&  
      return this.filter(function(){ 
        jQuery.inArray( this, selector ) 
      })

comment:6 Changed 6 years ago by d.wachss

OK, I can't get WikiFormatting to listen to me. Ignore the first ! in the code above.

comment:7 Changed 6 years ago by flesler

  • Cc scott.gonzalez, john added
  • Component changed from core to selector
  • Milestone changed from 1.2.4 to 1.3

comment:8 Changed 4 years ago by dmethvin

  • Status changed from assigned to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.