Check out a free preview of the full The Good Parts of JavaScript and the Web course

The "Retrieving Nodes" Lesson is part of the full, The Good Parts of JavaScript and the Web course featured in this preview video. Here's what you'd learn in this lesson:

Nodes can be retrieved using many different methods. For example, the document class has methods getElementById() and getElementByName(). There are many other methods for retrieving one or more nodes. After discussing node retrieval, Doug demonstrates how to manipulate node properties through getters/setters and explores the style API.


Transcript from the "Retrieving Nodes" Lesson

>> [MUSIC]

>> Douglas Crockford: You can get a node by retrieving. The way I prefer to do it is get document.getElementById. You can also get things by name, by tag name. You can do CSS queries and things like that. There's quite a lot of ways of getting access to a node now.

Once you have access to a node, you can manipulate it. So these are the standard properties of an image tag. And if you have access to an image tag, you can change any of these properties. The most interesting one to change is the source if you replace the source with a different URL.

Then suddenly a different picture will show up. And JavaScript provides a very convenient way of doing that. You just say name equals whatever value you want it to have and it works. These are the standard properties of an image tag. Every browser will have additional properties that are unique to that browser.

I recommend stay away from that stuff because it's a trap. If you wanna stay to the common part, so you'll work everywhere. W3C was not happy about JavaScript, surviving in the web after they'd rejected it. They thought that was gonna be the end of it but it didn't and there was a lot more sympathy for Java at W3C than for JavaScript.

And so over the years they've been trying to replace the API with something that would be more friendly for Java than for JavaScript even though Java has never lived in browsers in this way. So they didn't like the old school way of doing things. So they added this one, we can call get tribute and set tribute.

This form having the obvious advantage, that's a lot more typing and people like that.
>> Douglas Crockford: Another thing you can do when you've got hold of a node is style it. So you've got lots of options for styling. One is you can get at its class name, which is a misnamed thing.

it should be .class but it's not, it's called class name even though it can be several class names. It's still class name. More interesting as you can get at style object and change attributes of the style. Microsoft added a really nice thing called currentStyle but sometimes you want to know what is the current attribute for something.

I want to know how big something is or where it is or what color it is currently. Something like that. And Microsoft provides a very nice way of finding that out. But W3C said, no that's not the way we wanna go. Instead we'd rather have you write document.defaultview.getcomputed style node get property values style name, right.

This is obviously a Java API, right. I mean nobody who knows JavaScript would write that. This is clearly designed by somebody who did not know anything about JavaScript. And I don't know what happens with people in the Java world that they wanna write stuff like this but that's kind of the way things happen.

So I need to rant for a moment. So the CSS and the DOM were both designed about the same time. And each project was aware of the other. The guy who designed CSS was aware that some day programming languages were going to manipulate style sheets, not that was a certainty.

And yet he chose to use the minus sign as a hyphen, knowing that most of our programming languages want to do subtraction with it and that this creates a syntactic difficulty for all of you. He did that, anyway. Meanwhile, at Netscape they're working on the DOM and they see what just happened to CSS and they go.

Okay, what are we gonna do about that? What they could have said was, well, that's annoying but we'll just say you take the brackets and you put the string in, that's that, so. You have to type for extra characters but it was completely compatible. Or they could have said, well minus signs are a problem, so we'll just change them to under bars.

So minimal change, search and replace config, no. They went with the least compatible way of writing these names.
>> Douglas Crockford: And it matters, cuz you need to be aware of which space am I in right now? Am I in CSS space, or am I in DOM space? And it's really easy to get confused about where you are and if you pick the wrong form, it's total failure.

They could have made this work like a system. They could have made this work well for you and they chose not to and it's still there and it's never gonna get fixed. Anyway, so another thing you can do with nodes is you can make nodes. You can make brand new nodes.

So you can call document.createElement, pass in a tag name like a DIV or something and you get a new element. That new element is not visible yet and it won't be visible until you paste it into the tree. We'll do that next. You can make text nodes the same way.

You pass a string to create text node and it will make you a text node. Which you can then attach to some other node. Another way you can make nodes is by cloning nodes that you already have. A clone is not a perfect copy. For example a node might have event handlers on it, but a cloned node will not.

But otherwise it's pretty similar. And if you pass true to cloneNode, then if the node has children, you'll get clones of the children as well.
>> Douglas Crockford: So if you wanna make it visible, you have to stick it into the tree. So you can call a node and say appendChild, the new node.

And so the new node becomes the new last child of that node. And you can also insert things before and you can replace a node with a different node. And again, this is a Java API. Because you have to say old twice. Like I could just say, node, replace yourself with this.

No, you have to tell the nodes parent replace that child with that one in the way find the parent is with the node itself. Why do you have to write old twice? Why did Java people do that? Anyway, you have to remove children. And so you can call node.removeChild but again you don't tell the node to remove itself, you have to tell the parents to move it, so you have to do it twice.

There's a particular hazard here for garbage collection, if you're on one of the older IE browsers. So, anybody supporting IE6, 7, 8? You're breaking my heart. Really?
>> Speaker 2: Legacy, and it's, yeah.
>> Douglas Crockford: Okay, so I was hoping I wouldn't have to say this anymore but I do. So there is a design error in IE.

That if you attach a event handler to a node, that node will not get garbage collected. And the event handler and everything that it's holding onto will not get garbage collected even if you remove that node from the tree. So, the requirement is that you have to remove all of the event handlers from the node before you remove the node from the tree.

Which is too much to ask of anybody but that's what you have to do. It was identified in IE6, it was supposed to be fixed in IE7, and it wasn't. It was supposed to be fixed in IE8 and it wasn't. I believe it finally did get fixed in IE9.

>> Douglas Crockford: So sometimes what you want to do is take a fragment of HTML text and incorporate that into the document somehow. And W3C in their API provided no good way to do that. Their model was, you would write an XML parser in JavaScript. And have it parse the text, and then you would call all the methods that I just showed you and have it build the structure.

Microsoft said, no that's way too much work, so they came up with a property of a node called innerHTML, which is a terrible name. But it works. So, what you do is your assign an HTML text fragment to that and it will parse it and turn it into a tree and stick it into the document, do all of that, very nice.

Unfortunately, it's a security hazard. Any time you have any manipulation of HTML text, particularly by concatenation but also by templating, there is a good chance that an attacker can exploit that. So you need to be really, really cautious with this stuff. So which way is better? Is it better to build or clone elements and append them to the document or is it better to compile in HTML text and using HTML to realize it.

Generally, these sorts of questions I want to answer in terms of, what gives you a cleaner code and better maintenance? Now, what best matches the way you make the application that you should only favor performance in cases where it really matters? In the cases where it really matters, you wanna use in our HTML.

It's one of the few things that browsers are really good at is parsing HTML. And they can do that really quickly and they can get the whole thing done in one transaction. Whereas messing with the DOM, every time you touch the DOM you're gonna pay a big time penalty.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now