grabbing an attribute in mootools: .[name] or .get or .retrieve or .getProperty?
Something I ran into just now was returning an anchor’s attribute consistently across browsers. So I have an anchor with an address like ‘/users/delete/5/’ which does what you’d think it does. But I ran into an inconsistent return response in (you guessed it) ie6. In all fairness, it might not be IE6’s fault, but it speaks more to a problem with mootools. While it is a nearly perfect library/framework, this does bug me.
Mootools has 3 native methods for accessing an attribute/property for a node (which in the DOM, often overlaps). .get(’name’), .retrieve(’name’), and getProperty(’name’). While they are all meant to do things a little differently (eg. set an attribute for a node, store a data object in an existing object (which could be a DOM node) or store a property in an object (which again, could be a DOM node), they seem to overlap a lot.
So I have this anchor, and when I tried accessing it (grabbing the href) using the accessors I have, here at the results for FF (mac) vs. IE6 (windows):
.[name]
FF: full path including host
IE6: full path including host
.get
FF: request path (excluding host)
IE6: full path including host
.retrieve
FF: null
IE6: null
.getProperty
FF: request path (excluding host)
IE6: full path including host
Now it’s hard to say what is the correct expectation. I’m sure I could figure it out in the eyes of the W3C, but rather, here’s what I’ve noticed. Both browsers take whatever path is specified and render it internally with the host. I understand this since it’s what the browser would need to actually make a full request.
The 2nd and 4th accessors, though, are inconsistent and cause problems since their expected results different. IE6 includes the full path & host each time which is most likely an issue with how it accesses it. When the browser defines the href in memory it must overwrite the local pointer which then can’t be accessed properly.
So what do I do about this? Nothing really. I have this documented now so that if there is a pre-dom-ready source that I need to inspect (for example, href values written but no rendered after the dom has been loaded), I should be using the .[name] accessor, and make adjustments accordingly based on what is being accessed (in this case the href which has the host prepended).
These differences really suck since they introduce inconsistencies in places where you wouldn’t expect them and thus break applications/scripts (like what drove me to discover this). I would hope a framework/library would help mitigate this kind of thing, but alas, they can’t do everything, and I’m just happy for what they do bring to the table.
IE6 and input type changes: short answer, ie6 sucks, long answer:
The Problem
I ran into another problem the other day native to ie6 (well ie7 and ie8 too, to be fair) where by I was trying to dynamically change a text input field from type=”text” to type=”password”. Safari, chrome and firefox had no issues. It was a simple as node.type = ‘password’, or since I was using mootools, node.set(’type’,'password’). Resolved. But wait…
Then I ran into IE6, whereby I got a nice “This command is not supported.”. It took me a while to figure this out. At first I thought the node didn’t have mootools ’set’ method for some reason (didn’t access it right?), but once I found out the reason, I looked for workarounds. None really. Other resolutions that attempted completely different code, but no workaround for IE6 specific to change the type. It seemed microsoft had decided that an input field’s type should not be able to change after it’d been loaded. I’ll get to that in a second
My Resolution
Spit out password fields on the page for when it gets sent back to the client. When the DOM has loaded, iterate over the input[type=password] fields (I did this via the mootools selector node.getElements(’input[type=password’)), make them hidden (via add a class or adjusting it’s style property), and make a new node that has an input type with the text value. I added the same classes to it as the password node had. When a user focused on the field (the text one that was originally a password field), I destroyed it, and removed the hidden class.
What really bothered me
“This is an expected behavior. One can’t change the type of an INPUT element once it is already created and became part of the DOM. The behavior is documented below in the Remarsk Section:”
That was microsoft’s response in their developer forums. That was last year, and instead of addressing it as an issue and complying with a standard, they were stubborn and basically refuted the claim as a bug. I’m not sure how I feel about the standard. I understand why an input type is set after the DOM has been loaded. I can’t change a tag type from div to span after the fact (or at least I shouldn’t be able to). Ideally, in my own head that is, every input type should have a separate tag value. <button />, <select />, <file />, <text />, <textarea /> and <password />. I think that’d be ideal, and save a lot of confusion.
Either way, that’s my resolution. M$ response is kind of sucky, but what can ya do.