Opened 13 years ago
Closed 13 years ago
#6474 closed bug (worksforme)
strange behavior of has() and eq()
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | Milestone: | 1.4.2 | |
Component: | selector | Version: | 1.4.2 |
Keywords: | eq, has | Cc: | |
Blocked by: | Blocking: |
Description
some code html:
<select name="1"> <option>0</option> <option>1</option> </select>
<select name="2"> <option>0</option> <option>1</option> <option>2</option> </select>
<select name="3"> <option>0</option> <option>1</option> <option>2</option> </select>
I expect, that query $('select:has(option:eq(2))') return select[name=2] and select[name=3], but returned nothing. But query $('select').has('option:eq(2))') return only select[name=2].
It's like as "has" selector find all options, instead of options in current select as in find function.
Change History (2)
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Yep, rsinton is right. Take a look at the :nth-child
selector as well.
Not a bug.
:eq(n) doesn't do what you're expecting: it selects element n from an array of results -- check the docs for more details.
What you want is
$('select:has(option:contains(2))')
.Your second example is working correctly, in that it finds the third option element in the document ( eq(2), because the array is zero-indexed), then returns the select element that does contain that option element.
Some examples to clarify: