As opposed to just accessing the values as normal properties of a scripted object... I've been seeing a lot of coders using it, when I was under the understanding that setAttribute couldn't be relied upon due to a certain browser (gee, I wonder which one that could be!) It's more code, for something that should already exist on the DOM -- so why does it 'need' to be a method in the first place? My google-fu is telling me that yes, it shouldn't be used and is unreliable... http://reference.sitepoint.com/javascript/Element/setAttribute But I prefer to understand why it even exists since it's completely and pointlessly redundant to just accessing the property directly. It's one of those "and who thought this was a good idea?" moments. Is there some legitimate difference, or is it just another of those oddities where the folks who made JavaScript said "let's make this even MORE complex"?
The short answer is that attributes are in the HTML and properties are in the DOM. And in *most* cases they are somewhat interchangeable. But not always... for example: <input type="text" value="something" /> HTML: value is an attribute of input, and is part of the HTML itself. But say a user types "blah, blah" in that input box... "blah blah" is the property (it exists only in the page DOM), the underlying value attribute did not change in the HTML, so if you had JavaScript that changed the attribute, it wouldn't change the text that the user typed in the input box and vice versa.
That would almost make sense for getAttribute, but not for setAttribute... and once the DOM is loaded or if you are creating a new DOM element from scratch like a good little doobie instead of using innerHTML, setAttribute just doesn't make any sense... Besides you use setAttribute on an existing element not one browser out there changes the markup on view->source, and if you use 'view generated source' or it's equivalents in tools like the "web developer" extension, setAttribute or DOM.property will both show up... I'm gonna put together a test-case just to see all the different ways the two are resolved -- using not just the setAttribute method, but also comparing getAttribute vs. the DOM. To me I just can't see any practical reason for the method versions to even exist, much less be favored as much as they seem to be by JS devs, particularly with it's browser specific shortcomings. Can anyone think of a specific testcase (with example code) that would show why you'd even use the methods instead of the properties?
Not true, Shawn. http://www.thomasmottl.com/test.html Edit: I must have misunderstood Shawn's post. I thought he was saying that the set/get attribute was required to access the value of the form field. Disregard this post.
I can't think of a lot of real world reasons you would want to change the attribute rather than the property, but I'm sure there is some weird scenario where you might. Like maybe you have a JaveScript system that outputs HTML and as a basis it reads them inner HTML of part of the page. {shrug}
Ok, in working on something else I think I found ONE scenario where it does in fact make a difference: input[reset] Input.value == live/active copy Input.setAttribute will change what hitting a input[reset] will reset it to AND the current value. Still though, that means 90% of the time (not to pull a number out my backside) using setAttribute is just wasting a method call/overhead... but at least there seems to be a reason for it to exist. Interestingly it also means getAttribute will get the value the page was sent with on an input, while DOM.value returns what it currently is. Alright, that makes sense. Thanks guys, this one's bugged me for a while.