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.
Related
I modified this and am moving this comment to the top.
In keeping with Stackoverflow, this could be a bug in some underlying things that no one can fix. But I will consider the best method you propose keeping within the framework of our application to remove the spurious attribute as the solution. It would be unfair otherwise.
I have an oddity I am trying to solve which is baffling. First, it's unclear that it is IE except this behavior does not happen on Chrome or Firefox. We are using charting libraries from Anychart and D3 to generate SVGs on a page. All of this is great. The application is a printing application and extracts the resolved css + html into a separate div and sends this via REST to a formatting service.
The issue lies only in IE and only with the Anychart chart. If you examine this page:
http://www.xportability.com/XEPOnline/FOTestSuite.html
And look toward Image Example #4, you will see a chart. Using IE and DOM explorer, you will see this:
All looks fine. In fact all is fine if that was "real". If you use javascript to extract that SVG in anyway (simplest method is copy HTML in Explorer DOM), you will see that this element's HTML is actually:
<svg xmlns="http://www.w3.org/2000/svg" width="800" height="600" xmlns="http://www.w3.org/2000/svg">
Even using document.getElementById("anychart").outerHTML in console returns this element this way.
Note the double declaration of the namespace. Well, that is the issue as that is an error.
It does not happen on the D3 chart, nor the static chart. only this chart.
It does not happen in Chrome nor Firefox.
And most odd, it does not even display this way in IE's own DOM explorer.
Am I missing something here? Is there something else we are doing that is making IE do this?
NOTE: I am not looking for answers like apply the regex against the serialized string or such. We can do that (in fact we already do) to close empty (non-closed) HTML tags to make valid XML.
NOTE2: I am not discounting the fact that this could exists in the underlying Anychart JS library used or be a bug in Internet Explorer. It does only appear using Anychart library. They have been contacted to comment. However, the fact that IE shows only one namespace in the DOM explorer and then two when exporting is suspect that it is an IE issue potentially. They have also been contacted through their support.
So, I understand there may be no "answer" to this question .. it could be a bug in another library or in a browser.
As such, this demo only works in Chrome and Firefox for the moment ... until we hack around this or solve in some other way.
After deep analysis Anychart Javascript library was the culprit. They fixed the bug and this does not happen anymore.
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.
I've seen several threads about reading contents, but nothing on writing to noscript.
$('body').append('<noscript><div></div></noscript>');
In Chrome and IE9 I get a noscript-element with a empty div inside like I expect, but in IE7 and IE8 I just get a empty noscript-element without the div inside.
Example: http://jsfiddle.net/cEMNS/
Is there a way to add HTML inside the noscript-tag that works in all browsers? What I need is to add some tracking code into a noscript-element at the end of the page, but the info I need isn't available until after document ready.
Edit: I'm getting a lot of comments on "why". It's some poorly done tracking library that requires this. We don't have access to the code to change it. Regardless, I find it interesting that it works in some browsers and not in others since jQuery was supposed to work equally in all browsers. Is it simply a bug?
Edit2: (2 years later) Adding a noscript on the browser doesn't make sense, I know. My only excuse not the question the task I had was because of lack of sleep, like everyone else in the project. But my rationale was that jQuery should behave the same on all browsers and someone might want to do this on the server.
Regardless of the tracking code, what you are doing (or are required to do) makes no sense!
Why? There are two cases possible here:
user has JavaScript enabled in which case the NOSCRIPT get's inserted into the DOM but is ignored by the browser (does nothing)
user does not have JavaScript enabled, NOSCRIPT does not get inserted and does not "execute"
The end result of both cases is that nothing actually happens.
Just an idea: You could try giving your noscript tag an ID, and then try to use native js.
for example:
$('body').append('<noscript id="myTestNoScript"></noscript>');
document.getElementById('myTestNoScript').innerHTML = '<div></div>';
I would claim that if it does not work with native js, it will not work with any library (feel free to correct me on this one).
I tried following simple HTML code:
<html>
<body>
<noscript>I'm a noscript tag.</noscript>
</body>
</html>
Then I did analyse this with IE8 (in IE7 mode) and his integrated code insprector. Apparently the IE7 checks are script allowed. If so he declared it as empty. And empty tags will be ignored. Unfortunatly I could not try that with disabled script option, because only the Systemadministrator can change the settings (here at my work).
What I can assure you, the noscript does exists. If you add
alert($('noscript').size());
after the creation, the result will be 1.
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?
I am testing the speed of different methods to dynamically add html elements to the DOM. I've build a tester here (code is working version, so pretty sloppy). The results are (very) different for different browsers with Chrome getting all the points for speed, and Opera a good second - but that's not the question here.
In Firefox I detected a problem with clearing a div (from it's childNodes). When some 50.000 div elements are added, it takes ages to clear, using just
[div].innerHTML = "";
What is going on here? Did firefox implement some intrinsic garbage collection method for this?
While I am not sure about the innerHTML = "" you left out one possibly fast appoach using DocumentFragments for inserting into the DOM: As John Resig shows.
As Ólafur Waage already mentioned, even though innerHTML is faster in a lot of situations since it's not part of any W3C standard, quirks are far more likely to be introduced then if they were. Not to say innerHTML is not a defacto standard within modern browsers.
This blog post seems to indicate that Firefox spends a lot of time cleaning up after itself when using innerHTML to remove elements.
In some browsers (most notably, Firefox), although innerHTML is generally much faster than DOM methods, it spends a disproportionate amount of time clearing out existing elements vs. creating new ones. Knowing this, we can combine the speed of destroying elements by removing their parent using the standard DOM methods with creating new elements using innerHTML.
innerHTML is not a part of the W3C DOM specification.
It should never be used to write parts of a table—W3C DOM methods should be used for that—though it can be used to write an entire table or the contents of a cell.
As there is no public specification for this property, implementations differ widely. For example, when text is entered into a text input, IE will change the value attribute of the input's innerHTML property but Gecko browsers do not.
For those wishing to adhere to standards, here is one set of JavaScript functions offering to serialize or parse XML so as to set element contents defined as string(s) via the DOM or getting element contents obtained from the DOM as a string.
Source - Mozilla Dev