Is nodeIndex a valid DOM element property in IE? - javascript

I came across some javascript at work today that used jQuery to fetch two elements. It then used elem.nodeIndex to determine the position in the elements parent for each element. Nothing is setting this property anywhere and I do now see a reference to it in the msdn, mdc, or anywhere else.
I stepped through this javascript in FireFox with FireBug and tested the code in chrome and opera. I am sure nothing was trying to set this property. However, I can't find any information on this nodeIndex property anywhere.
Does nodeIndex exist as a DOM property in IE, or did I miss something while debugging my code?
UPDATE: I asked the same question on the jQuery list and they confirmed the property is for internal use only.:

It looks like it's jQuery that's adding nodeIndex to nodes in some cases.

Well, the easy answer is: If it isn't documentated anywhere like MDC, MSDN or W3, then it isn't a 'real' DOM property.
The idea of using nodeIndex, is also wrong, why would you want to do that?

Related

Accessing an HTML-element by it's id DIRECTLY - What happens here?

I've discovered this behavior by accident:
I can access an HTML-element in JavaScript just by it's HTML attribute "id". Normally I used getElementById for that.
I have even write-access to it's properties.
Made this demo and tried it out in Firefox, Safari and Chrome.
It worked everywhere.
alert(test1.innerHTML);
test1.innerHTML = 'Foobar';
alert(test1.innerHTML);
<div id="test1">Demo 123</div>
So, to be honest: I'm astonished and confused because I haven't known that that's possible.
Moreover I ask myself: What sense does getElementById make when I can get and set the element directly?
Sure: I'm aware that the inventors haven't incorporated the method without some intention.
Can anyone give me some explanations why I have access to elements via id-attribute?
And why one uses getElementById nevertheless?
As far as I remember, this behaviour was introduced by Internet Explorer. After a while, other vendors picked it up. I don't think it was ever standardized and, as such, might stop functioning at any time. Also, if you have a variable test1 in your code it will override the test1 defined by the controls.
Worth mentioning, in certain IE versions, trying to create a global variable with the same name as the id of an element fails. The book "JavaScript: The Definitive Guide" by David Flanagan also says that if the variable already exists in the global scope when the element is created, then the variable will not be overwritten by the element with the same id.
More on the subject here: Is there a spec that the id of elements should be made global variable? and here: Do DOM tree elements with ids become global variables?

Selecting a DOM element using javascript document.myElementsName

I'm working on a website which was coded a while ago.
I've found a Javascript function that uses the following syntax to set a value for a text box
document.myForm.myText.value = "value";
I've tested this code and it works in IE, Firefox and Chrome.
My question is whether this way of setting/selecting DOM elements is ok going forward (ie. is it going to get depreciated)? Should I change instances of this type of element selecting to the more standard (in my experience) code below?
document.getElementById("myText").value = "value";
Thanks in advance.
I don't think it'll make a difference cause the browsers dom representation will have change to break the code; That'll probably break half the web pages on the internet.
Your code is better than the first because you will then be coding to the contract of the method getElementById, which returns the HTMLElement you need. This means that the JS Engine has to adhere to the standards of ECMAScript and return the exact element. Hence your code doesn't need to worry if tomorrow a browser changes it's structure and your element is now document.forms.myForm.myText.value instead of what you anticipated.

How can I view the data attributes value live in the chrome developers tool?

I want to see the values as I explore the DOM in the developers tool. And also if possible see what binded to the element javascript wise. Is this possible using some plug in or how would I go about doing this?
Data attributes can be seen on the element: http://cl.ly/0w3V2H311E21241J2j45
If you're using jQuerys .data(), it doesn't change the data attributes of the element, so you have to call .data() to get it see it. I am not aware of any plugins that allow you to view it in the DOM explorer.
Event listeners can be found to the right by clicking on the element. Scroll down to the bottom of the CSS rules and you will see a section called "Event Listeners": http://cl.ly/2f3c3z312c3D2w43321s
Sorry if you are limited to use only Chrome developer tools.
However for others who can use Firefox it may be useful to know that there is a great extension for Firebug: FireQuery, which is doing exactly what you ask plus other nice things.

AppendChild issue with Internet Explorer Javascript

The following piece of code, works correctly in Firefox and Chrome, but it gives me a headache in IE.
var anotherDiv= document.getElementById("anotherDiv");
var destination = document.getElementById("mySourceDiv");
destination.appendChild(anotherDiv);
I'm trying to get a Div element and place it inside another div.
I get an error message (in the debug console in IE) similar to "interface not supported", and points me to the appendChild line.
What I've seen is that the type of the destination variable is an object rather then a DOM element.
What can I do to append the anotherDiv to mySourceDiv?
I'm trying this in IE 8.
You probably will need something like an importNode, there are various cross browser solutions around. The issue is that each node has a corresponding document object on it, in IE and so called security doesn't play nice moving things from one document to another.
So, essentially it's doing a deep clone, but the difference between using cloneNode is that cloneNode also sets the document which you don't want.
This might get you going in the right direction:
IE support for DOM importNode
I'd recommend using a library designed to sort through the browser incompatibilities for you. I've personally found jQuery to be quite good. jQuery has an append function.

DOMCharacterDataModified not firing consistently across Firefox and Chrome. Who is correct?

I made this fiddle that listens for a few different MutationEvents, specifically DOMCharacterDataModified, DOMSubtreeModified, and DOMNodeInserted when changing the innerHTML of a div.
http://jsfiddle.net/newtang/kysTm/15/
Interestingly, Chrome shows:
DOMCharacterDataModified, DOMSubtreeModified
while Firefox 5 shows: DOMNodeInserted.
I'm not actually sure who's correct. I found this old Mozilla bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=368133 and the W3 docs (http://www.w3.org/TR/DOM-Level-2-Events/events.html), but I don't find either particularly enlightening.
Does anyone know what the proper behavior is? I'd love to file a bug on someone so it's consistent.
WebKit has an "optimization" where if you set innerHTML to something that contains no markup and the first child of the node you're setting it on is a Text node they will modify the text in the textnode directly instead of doing what the spec calls for (removing all the children and creating a new Text child). Hence the difference in mutation events.
Firefox's behaviour seems to be correct. You setting the innerHTML, so you do not change the characterData of an existing textNode, you insert a new textNode and remove any existing contents .(You may also observe DOMNodeRemoved in your example, you'll see that it fires too)
See the difference when really modifying the data of a textNode: http://jsfiddle.net/doktormolle/yQu8v/

Categories

Resources