You can change the CONTENT of a page...

So far, most of the apps we’ve built have sent requests, gotten a response, and then used that response to update part of a page’s content.

... or you can change the STRUCTURE of a page

But what if you need to do more than just change the content of a <div> or replace the label on a button? What if an image needs to actually move on a page? How would you accomplish that?

Your users can’t change your XHTML.

The structure of your page is defined in your XHTML, and people viewing your pages definitely can’t mess around with that structure. Otherwise, all the work you’d put into your pages would be a total waste of time.

The browser CAN change your web page’s structure

You’ve already seen that the browser lets you interact with a server-side program, grab elements from a page, and even change properties of those elements. So what about the structure of a page?

Well, the browser can change that, too. In fact, think about it like this: in a lot of ways, the structure of your page is just a property of the page itself. And you already know how to change an object’s properties...

Browsers use the Document Object Model to represent your page

Note

Most people call this the DOM for short.

The browser doesn’t see your XHTML as a text file with a bunch of letters and angle brackets. It sees your page as a set of objects, using something called the Document Object Model, or DOM.

And everything in the DOM begins with the document object. That object represents the very “top level” of your page:

The document object is just an OBJECT

You’ve actually used the DOM, and in particular the document object, several times. Every time you look up an element, you use document:

In fact, every time you treat an element on a page like an object and set properties of that object, you’re working with the DOM. That’s because the browser uses the DOM to represent every part of your web page.

Here’s the XHTML that you write...

When you’re creating a web page, you write XHTML to represent the structure and content of your page. Then you give that XHTML to the browser, and the browser figures out how to represent the XHTML on the screen. But if you want to change your web page using JavaScript, you need to know exactly how the browser sees your XHTML.

Suppose you’ve got this simple XHTML document:

... and here’s what your browser sees

The browser has to make some sense of all that markup, and organize it in a way that allows the browser—and your JavaScript code—to work with the page. So the browser turns your XHTML page into a tree of objects:

Brain Power

How would YOU order and relate these different parts of the DOM tree?

The browser organizes your page into a tree structure, with a root and branches.

When a browser loads an XHTML page, it starts out with the <html> element. Since this is at the “root” of the page, <html> is called the root element.

Then, the browser figures out what elements are directly nested within <html>, like <head> and <body>. These branch out from the <html> element, and they have a whole set of elements and text of their own. Of course, the elements in each branch can have branches and children of their own...until an entire page is represented.

Eventually, the browser gets to a piece of markup that has nothing beneath it, like the text in a <p> element or an <img> element. These pieces of markup with nothing under them are called leaves. So your entire page ends up being one big tree to the web browser.

So let’s look at that tree structure again, but this time, with some lines added to make the connections between the markup a little clearer.

Your page is a set of related objects

There are no Dumb Questions

Q:
Q: Do I need to use a request object to write JavaScript code that uses the DOM?
A:
A: Nope. The browser handles creation of the DOM tree and exposes all the methods of the document object automatically. In fact, even when you’re not writing JavaScript at all, browsers still use the DOM to represent your page.
Q:
Q: So if the DOM doesn’t use a request object, is it really part of Ajax?
A:
A: Depends who you talk to. Ajax is really just a way of thinking about web pages, and a whole slew of other technologies, that helps you achieve interactive pages in really usable ways. So the DOM is definitely a part of that. You’ll use the DOM a lot in the next couple of chapters to build interactive and usable apps.
Q:
Q: What about all that DOM Level 0 and DOM Level 2 stuff? Am I going to have trouble with Internet Explorer again?
A:
A: All modern browsers are compatible with the World Wide Web Consortium’s (W3C) DOM specification, but the specification leaves some decisions up to the browser designer. The designers of IE made a different decision about how to build the DOM tree than a lot of the designers of other major browsers. But it’s not a big problem, and with a few more utility functions, your code will work on all major browsers, including Internet Explorer.
Q:
Q: It looks like you called some parts of the markup “children.” So an element can have “child elements”?
A:
A: Yes. When the browser organizes your XHTML into a tree, it begins with the root element, the element that surrounds everything else. Then, that element has an element within it, like <head> or <body>. Those can be called nested elements, but in DOM, they’re called child elements.
In fact, you can think of the DOM tree as a family tree, with family terms applying everywhere. For example, the <head> element is the parent of the <title> element, and most <a> elements have children: the text label for the link.
Q:
Q: You’re throwing a bunch of new terms around. How am I supposed to keep up with all of this?
A:
A: It’s not as hard as it seems. Just keep the idea of a family tree in mind, and you shouldn’t have any trouble. You’ve been using terms like root, branch, and leaf for years. As for parent and child, anytime you move away from the root, you’re moving towards a child. The only term that may be totally new to you is “node,” and we’re just about to take a look at that...

Sharpen your pencil

It’s time to load markup trees into your brain. Below is an XHTML document. Your job is to figure out how a web browser organizes this markup into a tree structure. On the right is the tree, ready for you to fill in its branches and the relationships between each piece. To get you started, we’ve provided spaces for each piece of markup; be sure you’ve filled each space with an element or text from the XHTML markup before showing off your DOM tree to anyone else!

<html>
  <head>
    <title>Binary Tree Selection</title>
  </head>
  <body>
    <p>Below are two binary tree options:</p>
    <div>
    Our <em>depth-first</em> trees are great for folks who
    are far away.
    </div>
    <div>
    Our <em>breadth-first</em> trees are a favorite for
    nearby neighbors.
    </div>
    <p>You can view other products in the
      <a href="menu.html">Main Menu</a>. </p>
  </body>
</html>

Answers in Sharpen your pencil Solution.

Let’s use the DOM to build a dynamic app

Now that we know a bit about the DOM, we can use that knowledge to make our apps do even more interesting things. Let’s take on a project for the Webville Puzzle Company. They’ve been working on a bunch of new web-based games, and they need help with their online Fifteen Puzzle.

We’re not replacing content, we’re moving it

In a Fifteen Puzzle, you can move a tile into the empty space, which then creates a new empty space. Then you can move another tile into that new empty space, and so on. There’s always one empty space, and the goal is to get all the numbers lined up in sequential order, like this:

We need to move those tiles around... and that requires the DOM.

This is a perfect example of needing the DOM. We don’t want to just change the content of a table, or replace some text on a button or in a <p>. Instead, we need to move around the images that represent a tile.

Webville Puzzles is using a table with four rows and four columns to represent their board. So we might need to move an image in the third row, fourth column to the empty space in the third row, third column. We can’t just change the innerHTML property of a <div> or <td> to get that working.

What we need is a way to actually grab an <img>, and move it within the overall table. And that’s where the DOM comes in handy. And, as you’ll soon see, this is exactly the sort of thing that Ajax apps have to do all the time: dynamically change a page.

All Ajax apps need to respond DYNAMICALLY to users.
The DOM lets you CHANGE a page without reloading that page.

Brain Power

What specific steps do you think you’ll have to take to move an <img> from one cell of a table to a different cell?

You start with XHTML...

To really understand how the DOM helps out, let’s take a look at Webville Puzzles’ XHTML, and see what the browser does with that XHTML. Then we can figure out how to use the DOM to make the page do what we want.

There are no Dumb Questions

Q:
Q: There isn’t any request being made in this puzzle, is there?
A:
A: No, at least not right now. The program is all client-side.
Q:
Q: So this isn’t Ajax at all, is it?
A:
A: Well, that gets back to the “What is Ajax?” question. If you think Ajax apps are only ones that make requests using XMLHttpRequest, then this isn’t an Ajax app. But if you think of Ajax apps more as responsive, JavaScript-driven apps that are very usable, then you might decide otherwise.
Either way, this app is really all about controlling the DOM... and that’s something that will help your Ajax programming, no matter what you think constitutes an Ajax app.

Sharpen your pencil Solution

Your job was to write out exactly what steps you’d take. Assume you know which table cell was clicked on, and you also know the destination table cell. What would you do?

Get the child of the selected table cell
You could use getElementsByTagName(), but we know that the <img> representing the clicked-on tile is the child of the selected cell. So we can use the DOM to get that child element.
Get the child of the destination table cell
Once we start swapping things around, it’s going to be harder to keep the selected <img> separate from the destination <img>. So before we start moving things around, let’s get a reference to the <img> in the destination <td>, too.
Add the clicked on <img> as a child of the new destination table cell.
We need to move the <img> in the selected cell to the destination cell. So we can just add the clicked-on <img> to the destination <td>’s list of children.
Add the <img> in the destination cell as a child of the originally clicked-on table cell.
Now for the other part of the swap. We need to move the destination <img> under the <td> that was originally clicked on. Here’s why we got the reference to this <img> in step 2: since there are two child <img>’s under the destination <td>, having a reference already makes this easy.

Do you want to CHANGE an element or MOVE an element? There’s a big difference.

You could definitely write code that simply swaps out the values of the two <img>’s src properties, like this:

The problem with this is that you’re actually just changing the properties of an image, and not moving those images around on the page.

So what’s the big deal with that? Well, what about the other properties of each image? Remember that each <img> had an alt attribute?

If you change the src attribute, you’re only changing a part of the <img>. The rest would stay the same... and then the alt attribute would not match the image!

What you need to do is swap the entire <img> objects. That way, each <img> keeps its properties. The image doesn’t change, but the location of that <img> in the DOM tree (and on the visual representation of the page) does.

Every node has a parentNode property... but the parentNode property is read-only.

Every node in a DOM tree—that’s elements, text, even attributes—has a property called parentNode. That property gives you the parent of the current node. So for example, the parent node of an <img> in a table cell is the enclosing <td>.

But in the DOM, that’s a read-only property. So you can get the parent of a node, but you can’t set the parent. Instead, you have to use a method like appendChild().

appendChild() adds a new child to a node

appendChild() is a method used to add a new child node to an element. So if you run destinationCell.appendChild(selectedImage), you’re adding the selectedImage node to the children that destinationCell already has:

A new child gets a new parent... automatically

When you assign a node a new child, that new child’s parentNode property is automatically updated. So even though you can’t change the parentNode property directly, you can move a node, and let the DOM and your browser handle changing the property for you.

There are no Dumb Questions

Q:
Q: So I can use all the DOM methods from my JavaScript automatically?
A:
A: That’s mostly right. There are a few exceptions that we’ll look at soon, but for the most part, the DOM is yours to use from any JavaScript code you’re writing.
Q:
Q: And a DOM tree is made up of nodes, like elements and text, right?
A:
A: Right, but don’t forget about attributes, too. A node is pretty much anything that can appear on a page, but the most common nodes are elements, attributes, and text.
Q:
Q: And a node has a parent and children?
A:
A: All nodes have parents, but not all nodes have children. Text and attribute nodes have no children, and an empty element with no content has no children.
Q:
Q: What’s the parent of the root element?
A:
A: The document object. That’s why you can use the document object to find anything in your web page.
Q:
Q: Are there other methods to add child nodes like appendChild()?
A:
A: There sure are. We’ll be looking at lots of those in the next chapter.
Q:
Q: Why is this better than changing out the src property of an <img>?
A:
A: Because you don’t want to modify the image displayed; you want to move that image to a new cell. If you wanted an image to stay the same, with its alt tag and height and title, you’d change the src property. But we want to move the image, so we use the DOM.

You can locate elements by name or by id

If you think about your page as a collection of nodes in a DOM tree, methods like getElementById() and getElementsByTagName() make a lot more sense.

You use getElementById() to find a specific node anywhere in the tree, using the node’s id. And getElementsByTagName() finds all elements in the tree, based on the node’s tag name.

Watch it!

Watch the “s” in your method names.

getElementById() is Element, without an “s”, because it returns one element. getElementsByTagName is Elements, with an “s”, because it can return more than one element.

Sharpen your pencil

Here are a few questions to get your left brain into gear. Answer each before turning the page... and once you’re done, you might want to double-check your code for initPage() above, too.

Should the event handler for moving a tile be on the table cell or the image within that cell?
table cell (<td>)
image (<img>)
Why did you make the choice you did?__________________________________
___________________________________________________________________________
How can we figure out if an empty tile was clicked on?________________
___________________________________________________________________________
How can we figure out the destination cell for a tile?________________
___________________________________________________________________________

Answers in Sharpen your pencil Solution.

Your job was to write an initPage() function that set up the event handlers for the Fifteen Puzzle. What did you come up with? Here’s what we did:

Table Cells Exposed

This week’s interview: Interview with a new parent

Head First: So I hear you’re a new parent, <td>?

<td>: That’s right. I’ve got a sweet little <img> to call my own.

Head First: So is this your first child?

<td>: Well, it depends on who you ask. Some browsers say that <img> is my first child, but others think I’ve got a lot of empty children floating around.

Head First: Empty children?

<td>: Yup. You know, empty spaces, carriage returns. It’s nothing to worry about.

Head First: Nothing to worry about? That sounds pretty serious... you might have more children, and that’s no big deal?

<td>: Relax, it’s all in how you handle it. Most people just skip over all those nothings to get to my flashy little <img>.

Head First: This is all pretty confusing. Do you think our audience really understands what you’re talking about?

<td>: If they don’t know, I’ll bet they will soon. Just wait and see.

Head First: Well... hmmm... I guess... I guess that’s all for now. Hopefully we’ll make some sense of all this, and get back to you soon, faithful listeners.

There are no Dumb Questions

Q:
Q: Why do you have the puzzleGrid id on a <div>, and not on the <table> itself?
A:
A: DOM Level 2 browsers and Internet Explorer handle tables, and CSS styles applied to those tables, pretty differently. The easiest way to get a page with a table looking similar on IE and Firefox, Safari, etc., is to style a <div> surrounding a <table>, instead of the <table> itself.
Since it’s easiest to style an element with an id, we put the puzzleGrid id on the <div> we wanted to style: the one surrounding the <table> cell.
Q:
Q: So that’s why you used getElementById() to find that <div>, and not the actual <table>?
A:
A: Right. We could have put an id on the <table>, too, but it’s not really necessary. The only thing in the puzzleGrid <div> is the table we want, along with all those clickable cells. So it was easier to just find the <div>, and then find all the <td>’s within that.

Brain Power

What do you think <td> is talking about in the interview above? Are there any functions we’ve written or will write that might need to worry about those “nothing” children that <td> mentioned?

Can I move the clicked tile?

Now that the basic structure is in place, it’s time to get the puzzle working. Since a tile can only be moved to the empty square, the first thing we need to figure out is, “Where’s the empty square?”

For any clicked-on tile, there are six different possibilities for where the empty tile is. Suppose the user clicked the “10” tile on the board below:

Sharpen your pencil Solution

Here are a few questions to get your left brain into gear. Answer each before turning the page... and once you’re done, you might want to double-check your code for initPage() above, too.

Should the event handler for moving a tile be on the table cell or the image within that cell?
table cell (<td>)
image (<img>)
Why did you make the choice you did?
How can we figure out if an empty tile was clicked on?
How can we figure out the destination cell for a tile?

Joe: Why? The user’s clicking on “7,” not the second tile on the third row.

Frank: Well, they’re clicking on the table cell that image is in, too.

Jill: So suppose we put the handler on the image. And then when a user clicks on the image...

Joe: ...we swap that image out with the empty square...

Jill: Right. But the handler’s attached to the image, not the table cell.

Frank: Oh. I see.

Joe: What? I don’t get it.

Frank: The event handler would move with the image. So every time an image gets moved, the event handler moves with it.

Joe: So?

Frank: Well, we’re going to use the DOM to figure out where the empty square is in relation to the clicked-on image, right?

Joe: I guess so. What’s that got to do with the handler on the image?

Frank: If the handler’s on the image, we’ll constantly have to be getting the image’s parent. If the handler’s on the cell, we can avoid that extra step. We can just check the cells around the clicked-on cell.

Jill: Exactly! We don’t need to move to the image’s parent cell in our handler.

Joe: So all this is to avoid one line of code? Just asking the image for its parent?

Jill: One line of code for every click. That could be hundreds of clicks... or even thousands! Have you ever worked one of those puzzles? It takes some time, you know.

Joe: Wow. I’m not even that clear on how we’d find the empty square in the first place...

You can move around a DOM tree using FAMILY relationships

Suppose you wanted to find out the parent of an <img> or get a reference to the next <td> in a table. A DOM tree is all connected, and you can use the family-type properties of the DOM to move around in the tree.

parentNode moves up the tree, childNodes gives you an element’s children, and you can move between nodes with nextSibling and previousSibling. You can also get an element’s firstChild and lastChild. Take a look:

Use descriptive names for your elements and your id attributes.

When you’re writing XHTML, the element names are already pretty clear. Nobody’s confused about what <div> or <img> means. But you should still use descriptive ids like “background” or “puzzleGrid.” You never know when those ids will show up in your code, and make your code easier to understand... or harder.

The clearer your element names and ids, the clearer your code will be to you and other programmers.

Long Exercise

It’s time to get busy building the rest of the Fifteen Puzzle Code. Here’s your assignment:

Write a cellIsEmpty() function.
Given a node representing a <td>, figure out if the image in that cell is the empty image. To help you out, here’s the XHTML for the empty cell:
```
<td id="cell22">
  <img src="images/empty.png" alt="empty" width="69" height="69" />
</td>
```
Here’s part of the function to get you started:
Look for an empty cell in the tileClick() event handler.
Let’s start building tileClick(), the event handler we attached to each table cell. First, we need to check for an empty cell. If the clicked-on cell was empty, let’s show a message indicating the user needs to click on a different tile.
```
function tileClick() {
  if (cellIsEmpty(      )) {
    alert("Please click on a numbered tile.");
    _________________
  }
}
```

Figure out what row and column was clicked.

Here’s the XHTML for a couple of cells in the puzzle:

 <td id="cell13">
  <img src="images/14.png" alt="14" width="69" height="69" />
 </td>
 <td id="cell14">
  <img src="images/11.png" alt="11" width="69" height="69" />
 </td>
</tr>
<tr>
 <td id="cell21">
  <img src="images/12.png" alt="12" width="69" height="69" />
 </td>
 ... etc ...

Given this (and the rest of the XHTML, in You start with XHTML...), can you figure out how to get the row and column of the clicked on tile?

Finish up the tileClick() event handler.
Once we’ve made sure that the empty tile wasn’t clicked, and gotten the current row and column, you have everything you need. Your job is to handle the 5 remaining possible situations for where the empty square is, and then if possible, swap the selected tile with the empty square.
To get you started, here’s the code to check above the selected tile:
The rest of tileClick() is up to you. Refer back to the different possibilities you have to handle from Sharpen your pencil Solution, and good luck!

There are no Dumb Questions

Q:
Q: Wow, that was a lot of code. Am I supposed to understand all that?
A:
A: It is a lot of code, but if you walk through things step by step, it should all make sense to you. There’s not a lot of new stuff in there, but there’s definitely more DOM and positioning than you’ve done up to this point.
Q:
Q: And all of this is DOM code?
A:
A: Well, there’s really no such thing as DOM code. It’s all JavaScript, and lots of it does use the DOM.
Q:
Q: So which parts use the DOM?
A:
A: Anytime you use a property that moves around the tree, you’re using the DOM in some form. So firstChild and previousSibling are DOM properties. But code that uses getElementById() is also using the DOM because that’s a property on the document object. document is the top-level object of a browser’s DOM tree.
Q:
Q: Is it safe to assume the id of a table cell has the row and column in it?
A:
A: If you have control of the XHTML, like we do, it’s safe. Since the Webville Puzzles company set up their XHTML so that table cells had those handy ids, we were able to figure out a cell’s position by its id. If you had a different setup, you might need to figure out the cell’s position relative to other cells and rows.
Q:
Q: We could do that with the DOM, too, right?
A:
A: You bet. You’d probably be using some sort of counter, as well as previousSibling to figure out how many <td>’s over you are. And you’d need parentNode and similar properties to see which row you were on.
Q:
Q: So this DOM stuff can get pretty complex, can’t it?
A:
A: It can, very fast. Although lots of times, you’ll only need to get as complex as we had to for the Fifteen Puzzle. In fact, with just the properties you’ve already learned, you’re halfway to being a DOM master!
Q:
Q: Halfway? What’s the other half?
A:
A: So far, we’ve only moved around nodes in the DOM. In the next chapter, we’ll look at creating new nodes and adding those to the tree on the fly.
Q:
Q: Back to that code... so the firstChild of a table cell is always the image in that cell?
A:
A: That’s the way cellIsEmpty() is written right now, yes. Can you think of a case where an image would not be the first child of a table cell?
Q:
Q: If an image isn’t the first child of a table cell, that screws things up, doesn’t it?
A:
A: It sure does.
Q:
Q: Well, didn’t we do the same thing in swapTiles(), back in JavaScript & DOM Magnet Solution? We assume the image is the firstChild there, too, right?
A:
A: Exactly right. So would that assumption ever be false?
Q:
Q: Who’s asking the questions here, anyway?
A:
A: Maybe we should actually test out the fifteen puzzle, and see what happens.

The DOM is great for code that involves positioning and moving nodes around on a page.

Exercise

Here’s the XHTML for each table cell in the fifteen puzzle web page:

<td id="cell22">
  <img src="images/empty.png" alt="empty" width="69" height="69" />
</td>

Is there any difference between that XHTML and this fragment:

<td id="cell22"><img src="images/empty.png" alt="empty" width="69" height="69" /></td>

Take a close look at swapTiles() and cellIsEmpty(). Do you see a problem related to the difference in the two XHTML fragments shown above?

A DOM tree has nodes for EVERYTHING in your web page

Most XHTML pages don’t have every element, from the opening <html> to the closing </html> crammed onto one line. That would be a real pain to read. Instead, your page is full of spaces, tabs, and returns (sometimes called “end-of-lines”):

Those spaces are nodes, too

Even though those spaces are invisible to you, the browser tries to figure out what to do with them. Usually they get represented by text nodes in your DOM tree. So a <table> node might have lots of text nodes full of spaces in addition to all the <tr> children you’d expect.

The bad news is that not all browsers do things the same way. So sometimes you get empty text nodes, and sometimes you don’t. It’s up to you to account for these text nodes, but you can’t assume they’ll always be there. Sounds a bit confusing, doesn’t it?

There are some inconsistencies in how browsers treat whitespace. Never assume a browser will always ignore, or always represent, whitespace.

One browser might create a DOM tree for your page that looks like this:

Another browser might create a different DOM tree for the same XHTML:

The nodeName of a text node is “#text”

A text node always has a nodeName property with a value of “#text.” So you can find out if a node is a text node by checking its nodeName:

swapTiles() and cellIsEmpty() don’t take whitespace nodes into account

The problem with our code is that our functions are assuming that the <img> in a table cell is the first child of a <td>:

Sharpen your pencil

We’ve got to deal with browsers that are creating whitespace nodes in their DOM trees. See if you can fill in the blanks to fix up the swapTiles() and cellIsEmpty() functions below:

function swapTiles(selectedCell, destinationCell) {
  selectedImage = selectedCell.firstChild;
  while (selectedImage._______________ == _________) {
    selectedImage = selectedImage._______________;
  }
  destinationImage = destinationCell.firstChild;
  while (destinationImage._______________ == _________) {
    destinationImage = destinationImage._______________;
  }
  selectedCell.appendChild(destinationImage);
  destinationCell.appendChild(selectedImage);
}

function cellIsEmpty(cell) {
  var image = cell.firstChild;
  while (image.___________ == ____________) {
    image = image.______________;
  }
  if (image.alt == "empty")
    return true;
  else
    return false;
}

There are no Dumb Questions

Q:
Q: If the nodeName of a text node is always “#text”, how can I get the text in that node?
A:
A: Text nodes store the text they represent in a property called nodeValue. So the nodeValue for a whitespace node would be “”(an empty value), or possibly “ ” (two spaces).
Q:
Q: Shouldn’t we be checking to see if text nodes have a nodeValue of whitespace, then?
A:
A: In the table cells in the fifteen puzzle, there’s no need to check the nodeValue. Since we only care about <img> nodes, we don’t care about anything else. So we can skip over any node that’s a text node.

Did I win? Did I win?

All that’s left is to figure out when a player’s won. Then, every time two tiles are swapped, we can check this function to see if the board is in order. If it is, the player’s solved the puzzle.

Here’s a puzzleIsComplete() function that uses the names of each image to see if all the tiles are in order:

There are no Dumb Questions

Q:
Q: substr(-6, 2)? I don’t get it.
A:
A: A negative number means start at the end of the string, and count back. Since “02.png” is 6 characters, we want to go back from the end of the string by 6 characters.
Then, we want 2 characters of that substring, so we get “02” or “15.” So you use substr(-6,2).
Q:
Q: What in the world is that weird number you’re comparing the hash string to?
A:
A: It’s just every number in the puzzle, in order: 01, then 02, then 03, and so on, all the way to 15. Since the hash represents the orders of the tiles, we’re comparing them to a string that represents the tiles in order.
Q:
Q: But what about the empty tile?
A:
A: It doesn’t matter where the empty tile is as long as the numbers are in order. That’s why we drop the empty tile from being part of the hash string.

But seriously... did I win?

There’s even a special class that Webville Puzzles put in their CSS for showing a winning animation. The class is called “win,” and when the puzzle is solved, you can set the <div> with an id of “puzzleGrid” to use this class and display the animation.

That means we just need to check if the puzzle is solved every time we swap tiles.

The DOM is just a tool, and you won’t use it all the time... or sometimes, all that much.

You’ll rarely write an application that is mostly DOM-related code. But when you’re writing your JavaScript, and you really need that next table cell, or the containing element of an image, then the DOM is the perfect tool.

And, even more importantly, without the DOM, there’s really no way to get around a page, especially if every element on your page doesn’t have an id attribute. The DOM is just one more tool you can use to take control of your web pages.

In the next chapter, you’re going to see how the DOM lets you do more than just move things around... it lets you create elements and text on the fly, and put them anywhere on the page you want.

The DOM is a great tool for getting around within a web page.

It also makes it easy to find elements that DON’T have an id attribute.

Table of Contents for
6. The Document Object Model: Web Page Forestry

Chapter 6. The Document Object Model: Web Page Forestry

You can change the CONTENT of a page...

... or you can change the STRUCTURE of a page

Browsers use the Document Object Model to represent your page

Note

The document object is just an OBJECT

Here’s the XHTML that you write...

... and here’s what your browser sees

Brain Power

Your page is a set of related objects

Let’s use the DOM to build a dynamic app

We’re not replacing content, we’re moving it

Brain Power

You start with XHTML...

appendChild() adds a new child to a node

A new child gets a new parent... automatically

You can locate elements by name or by id

Watch it!

Brain Power

Can I move the clicked tile?

You can move around a DOM tree using FAMILY relationships

A DOM tree has nodes for EVERYTHING in your web page

Those spaces are nodes, too

The nodeName of a text node is “#text”

swapTiles() and cellIsEmpty() don’t take whitespace nodes into account

Did I win? Did I win?

But seriously... did I win?

Note

`document.getElementById("y");`	______________
`g.parent;`	______________
`document.getElementById("y").nextSibling;`	______________
`a.firstChild;`	______________
`c.parent.parent;`	______________
`d.firstChild.lastChild;`	______________
`c.previousSibling;`	______________

Table of Contents for 6. The Document Object Model: Web Page Forestry

Create new playlist

Sign In

Sign Up

Chapter 6. The Document Object Model: Web Page Forestry

You can change the CONTENT of a page...

... or you can change the STRUCTURE of a page

Browsers use the Document Object Model to represent your page

Note

The document object is just an OBJECT

Here’s the XHTML that you write...

... and here’s what your browser sees

Brain Power

Your page is a set of related objects

Let’s use the DOM to build a dynamic app

We’re not replacing content, we’re moving it

Brain Power

You start with XHTML...

appendChild() adds a new child to a node

A new child gets a new parent... automatically

You can locate elements by name or by id

Watch it!

Brain Power

Can I move the clicked tile?

You can move around a DOM tree using FAMILY relationships

A DOM tree has nodes for EVERYTHING in your web page

Those spaces are nodes, too

The nodeName of a text node is “#text”

swapTiles() and cellIsEmpty() don’t take whitespace nodes into account

Did I win? Did I win?

But seriously... did I win?

Note

Table of Contents for
6. The Document Object Model: Web Page Forestry