Inconsistency between has [attribute] selector and attr() method

Reported by:	jitter	Owned by:
Priority:	blocker	Milestone:	1.6
Component:	attributes	Version:	1.5.2
Keywords:		Cc:
Blocked by:		Blocking:

Description

While checking on #7480 I noted a related bug.

There are inconsistencies when using the has [attr] selector and the attr() method.\\\\The selector doesn't return all elements which have the attribute although upon checking with the attr() method it returns a value.

test case with text attribute not explicitly defined\\\\

test case with text attribute explicitly defined on some elements

Attachments (0)

Change History (5)

Changed November 12, 2010 10:29PM UTC by snover comment:1

_comment0:	This is something on the roadmap for 1.5. `.attr` will be rewritten along with Sizzle to stop matching on the DOM properties, so this will all be happily consistent again. → 1289601074024620
blockedby:	→ 7128
component:	unfiled → attributes
priority:	undecided → blocker
status:	new → open

This is something on the roadmap for 1.5. .attr will be rewritten along with Sizzle to stop matching on the DOM properties, so this will all be happily consistent again.

You will probably also notice here that the first test case will behave differently in IE6/7 because they run through Sizzle.

Changed January 17, 2011 04:55PM UTC by john comment:2

milestone:	1.5 → 1.6

This is getting moved to 1.6 for when the $.attr happens.

Changed April 02, 2011 04:54PM UTC by timmywil comment:3

I think #7128, #5930, and #5637 are duplicates of this issue, but I'm not 100% on that.

Changed April 15, 2011 04:06AM UTC by timmywil comment:4

blockedby:	7128

Changed April 15, 2011 04:07AM UTC by timmywil comment:5

resolution:	→ fixed
status:	open → closed
version:	1.4.4 → 1.5.2

The nodes in question do not have content attributes called "text" and therefore should not be found by either one. http://jsfiddle.net/timmywil/znVBU/2/

Side navigation

#7485 closed bug (fixed)