Via the MDN reference I want to simply do:
parent_element.removeChild(child_element);
However, in this particular case child_element has its own child elements.
Can I assume that this will not cause any problems and that they too will be removed.
The examples given in the reference did not make complete sense.
Yes when you remove an element from the DOM, all of its children are removed with it. If you are working with a modern browser, this is pretty safe. Older browsers tended to get memory leaks if you did not first remove all your event handlers before removing the elements.
Yes, all elements that are childs of a removed element are removed. You don't need to implement a deep removal yourself.
yes you can assume that the child's children will be removed
If the children didnt get removed, where or how could they exist in the DOM, unless someone put them somewhere else.
Related
I have an element #xxx and I have to select all children (any level) and all parent of this element. I dont want to select the element itself.
So far I've been using this jquery code but I am pretty sure there must be a way to make this more efficiently (maybe using addBack):
$("#xxx").find("*").add($("#xxx").parents())
Do you suggest any other alternative that does not make use of add() cause I think this selector is not efficient cause it queries internally again the #xxx. I think using addBack() would be nicer cause it does not cause another search for the element #xxx.
First time answering, please let me know if this is not the right way to do it.
But this is not a direct answer to your original question, but rather to your problem that you mentioned in the comments:
If I remove this selector and replace it with a simpler thing the scroll gets very smooth.
Since you are reusing the selector reference, perhaps you can store the selector, $('#xxx'), as a variable. Since the initial lookup is the heaviest part of the selector.
const $xxx = $('#xxx');
$xxx.find("*").add($xxx.parents())
Performance of jQuery selectors vs local variables
The link I want is always here first link of <tbody>. But maybe called something different.
If you could maybe explain what the code is doing that would be cool too. The simpler the code the better because I have to wrap it into an Applescript.
You could accomplish this with the following code based on your comments in your question and my answer.
document.querySelector('.odd').querySelector('a').click();
To provide a more permanent solution, more of the pages layout will need to be exposed.
What this does
document.querySelector and document.querySelectorAll queries the element nodes on the DOM. The first option will pull the first instance it finds for the search value, while the second will return all in a nodelist.
Running the click() function will simulate a click on that element you have queried for.
Knowing this, you can now take this example and potentially make a working script for yourself.
Let me know if this helps you out. Since you state the layout always stays the same, this should get you started.
This seems like an excellent situation to use find() since you'll always know the parent. Alternately adding a class to the anchor element would let you address it without crawling around the DOM.
$('.odd').find('a');
So if I have a <span class="iii"></span> container... and I use you know:
document.querySelector('.iii').outerHTML=''; it removes the span and essentially removes that span element from the DOM and everything inside of it correct? Is it really, technically deleting/removing it from the DOM? Does it perform what remove() does?
I ask this, because .remove() is a new experimental method that is not cross browser correct? I'm trying to find a cross browser way to 'remove an element', and outerHTML = ''; does that for me, but I am asking this question because it doesn't seem right. outerHTML's function isn't for deleting, (or can it be) or is it?
Edit: added .iii my bad.
There is no difference, both will remove the element from the DOM removing all event handlers and other related properties from memory when the garbage collector decides to. As for performance I wrote a quick test, http://jsperf.com/outerhtmlblank-vs-remove and it turns out that outerHTML = '' is 14% faster on Google Chrome so I would say that is better to use. Feel free to test on other browsers to confirm the results.
When you call outerHTML = '' it sets the HTML around it to nothing, then when the browser updates it's representation of the DOM it realizes that the element is now gone and removes it from the DOM whereas remove() simply removes it from the DOM.
There doesn't seem to be any significant difference between them when it comes to removing elements from the DOM. For your case they both remove the element, and that's the end of the story.
Here are the most obvious differences that come to mind (feel free to add any other ones):
outerHTML
It is a getter
It is a setter (for the setter version it can be used to either "remove" or "replace" an element)
When you're either removing or replacing an element, you don't need to know its parent like you would need to with el.parentNode.removeChild(el)
It works only with strings, which are then parsed into DOM objects
It is a property and not a method
It is supported by most Browsers
remove
It is a method
It can remove Element and Text nodes where outerHTML isn't available on text nodes
It can only work with DOM objects and not strings
You don't need to know the element's parent, instead you just remove it
It's not supported by most Browsers as it's new
I know that I can set it's style to "display: none"
However, that just hides it.
I really want to kill a DOM element and all of it's children.
The context is that I'm building a desktop-like GUI system (for learning purposes) inside of a DOM, and when a "window" is closed, I want that DIV and all it's children to be removed.
Thus, in JavaScript, how to I tell the GC "hey, get rid of this DOM element, it's no longer needed"?
Thanks!
To remove all elements, I suppose you could set element.innerHTML to an empty string (although I've never tried it myself). Otherwise, you could use element.removeChild(child), as described here.
jQuery also supports $([selector]).remove([selector]), which is more flexible in specifying which elements you want to remove at once. There's more information about jQuery remove here.
What about removeChild ?
See http://dustindiaz.com/add-and-remove-html-elements-dynamically-with-javascript/ for more information
I have been using elem.removeChild() to remove elements from my document, but saving a JavaScript reference to that element, so that I can add them back when appropriate. Works just fine in Firefox and Chrome.
Now I notice that that on IE7, those elements get destroyed in the process, having all their children removed. When I add them back to the same parent element, they are the same type of element and have retained things like their class name, but they have no children elements.
Is this expected behavior? I know I can change my app to do things differently, but it would take a good couple hours of reworking and I'd obviously like to avoid that. I've always assumed that it is ok to remove elements, either by using removeChild() or by setting the parent's innerHTML to an empty string, and as long as I had a reference to the element (i.e. a variable points to the element, not just an element id), it was ok to add and remove elements freely without having the element messed up.
Is this a bug with IE, am I somehow confused and something else is going on, or is this known and expected behavior?
The spec for removeChild doesn't explicitly say that the children of the node being removed should be kept along with that node, although to me it seems logical that they should and obviously that is what the FF and Chrome developers decided too. I don't know what the spec says to do if the parent's innerHTML is set to an empty string, but in my opinion that way is a bit like saying "wipe over whatever was there" so in that case I think it is reasonable for the browser to throw away everything that was in that innerHTML even if there were references in code to some of the removed elements.
Without seeing more of your implementation, I'm not sure you'll get more than blind answers; here's one:
Do you happen to be working with table rows? Check out this answer
. Apparently <tr> has to attach to <tbody> in IE, rather than directly to a <table>.