equals( jQuery("#table").attr("test:attrib"), undefined, "Retrieving a non-existent attribute on a table with a colon does not throw an error." );
equals( jQuery("#table").attr("test:attrib", "foobar").attr("test:attrib"), "foobar", "Setting an attribute on a table with a colon does not throw an error." );
- ok( jQuery("<div/>").attr("doesntexist") ===undefined, "Make sure undefined is returned when no attribute is found." );
- ok( jQuery().attr("doesntexist") ===undefined, "Make sure undefined is returned when no element is there." );
-
var $form =jQuery("<form class='something'></form>").appendTo("#qunit-fixture");
equal( $form.attr("class"), "something", "Retrieve the class attribute on a form." );
var $a =jQuery("<a href='#' onclick='something()'>Click</a>").appendTo("#qunit-fixture");
equal( $a.attr("onclick"), "something()", "Retrieve ^on attribute without anonymous function wrapper." );
+
+ ok( jQuery("<div/>").attr("doesntexist") ===undefined, "Make sure undefined is returned when no attribute is found." );
+ ok( jQuery("<div/>").attr("title") ===undefined, "Make sure undefined is returned when no attribute is found." );
+ equal( jQuery("<div/>").attr("title", "something").attr("title"), "something", "Set the title attribute." );
+ ok( jQuery().attr("doesntexist") ===undefined, "Make sure undefined is returned when no element is there." );
@timmywil
I'm not sure, but I don't think, that this is right. There are 3 things to consider:
The hooks do not match all cases, where this problem happens. (All attributes, which are also properties and not yet handeld special)
The hooks do match cases, where they return wrong values.
The code returns generally undefined, if the value is an empty string
Here two examples:
a title with an empty string will return now undefined. In case of the novalidate-attribute, this was already a problem for me:
<form novalidate></form> <!-- returns undefined in IE6/7 and "" in all other browsers -->
To fix this issue, I had to override jQuery's attr method. See here.
You should have this problem with a lot more attributes (for example with the id attribute) and there is a system behind this.
A code which should work more generic and less error prone, should generally check wether the attribute is also a property (IE6/7 mixes this) and then use the 'specified' property instead of the nodeValue property to decide wether the nodeValue or undefined is returned:
//only for ie6/7
var val;
if( !jQuery.support.getSetAttribute && name in elem ){
val = elem.getAttributeNode( name );
val = (val || {}).specified ? val.nodeValue : undefined;
} else {
val = elem.getAttribute( name );
}
return val;
Unfortunately, using specified was tried first but is not always correct so empty string is the best way I've found to make it consistent. This only pertains to title, name, and attributes on a form which do not have a value or are set to empty string as you've noticed (keep in mind empty string isn't really a valid value for id, title, or name but I understand the argument for consistency). Using specified would still return undefined in many cases, but the formHook opts for always giving the value if it is not empty string instead of sometimes missing out on the value if it's been specified but IE doesn't realize it. I've run into that many times. In the case of your plugin, I suggest adding a custom attrHook for novalidate and formnovalidate to take care of both, but I think we need another solution besides using specified, or perhaps a combination of solutions, but these really are all edge cases.
Oh, in case of title, the empty string is a not only valid, it is often used. For example, to override the alt-attribute behavior on img-element in IE6 and IE7. Mozilla also documents, that setting the title attribute to an empty string is the only way to remove the error-tooltip behavior on form elements, which are invalid.
Have you tested getAttribute(name, 0-5)? (I don't think that it works always, but maybee in those cases, where specified do not work. Often this does return really strange values).
timmywil
committed
timmywil
committed
aFarkas repliedJun 15, 2011
@timmywil
I'm not sure, but I don't think, that this is right. There are 3 things to consider:
Here two examples:
To fix this issue, I had to override jQuery's attr method. See here.
A code which should work more generic and less error prone, should generally check wether the attribute is also a property (IE6/7 mixes this) and then use the 'specified' property instead of the nodeValue property to decide wether the nodeValue or undefined is returned:
//only for ie6/7
var val;
if( !jQuery.support.getSetAttribute && name in elem ){
val = elem.getAttributeNode( name );
val = (val || {}).specified ? val.nodeValue : undefined;
} else {
val = elem.getAttribute( name );
}
return val;
The attr-basher is back again :-).
timmywil repliedJun 15, 2011
Unfortunately, using specified was tried first but is not always correct so empty string is the best way I've found to make it consistent. This only pertains to title, name, and attributes on a form which do not have a value or are set to empty string as you've noticed (keep in mind empty string isn't really a valid value for id, title, or name but I understand the argument for consistency). Using specified would still return undefined in many cases, but the formHook opts for always giving the value if it is not empty string instead of sometimes missing out on the value if it's been specified but IE doesn't realize it. I've run into that many times. In the case of your plugin, I suggest adding a custom attrHook for novalidate and formnovalidate to take care of both, but I think we need another solution besides using specified, or perhaps a combination of solutions, but these really are all edge cases.
aFarkas repliedJun 15, 2011
Oh, in case of title, the empty string is a not only valid, it is often used. For example, to override the alt-attribute behavior on img-element in IE6 and IE7. Mozilla also documents, that setting the title attribute to an empty string is the only way to remove the error-tooltip behavior on form elements, which are invalid.
Have you tested getAttribute(name, 0-5)? (I don't think that it works always, but maybee in those cases, where specified do not work. Often this does return really strange values).