Sublime Text (or Sublime, for short) is a popular text editor with several features that make it great for web development. In addition, it has the advantage that it’s cross-platform, which means it should work roughly the same whether you’re using Windows, Linux, or Mac OS. It’s not free, but you can download an evaluation copy for free and use it for as long as you like. If you do like the editor and find that you’re using it a lot, I encourage you to purchase a license.

Figure 1-1. An HTML document opened in Emacs

Figure 1-2. An HTML document opened in Vim

To install Sublime, visit http://www.sublimetext.com and click the Download link at the top. There you’ll find installers for all major platforms. Even though Sublime Text 3 is in beta testing (at the time of this writing), I encourage you to give it a try. I used it for all the examples and screenshots in this book.

Once you have Sublime installed and run it, you’ll be presented with a screen that looks something like Figure 1-3.

Figure 1-3. Sublime Text, after being opened for the first time

The first thing you’ll want to do is create a new file. Do that by going to the File menu and clicking New. You can also do that by typing Ctrl-N in Windows and Linux or using Command-N in Mac OS. Now type Hello World! into the editor. The editor will look similar to Figure 1-4.

You can change the appearance of the Sublime environment by going to the Sublime Text menu and following Preferences → Color Scheme. Try out a few different color schemes and find one that is comfortable for your eyes. It’s probably a good idea to spend some time exploring the theme options because you’ll spend a lot of time looking at your text editor. Note that you can also change the font size from the Font submenu under Preferences to make the text more readable.

Figure 1-4. Sublime after a new file is opened and Hello World! is typed into the file

You probably noticed that Sublime changed the tab name from “untitled” to “Hello World!” as you typed. When you actually save, the default filename will be the text that appears in the tab name, but you’ll probably want to change it so that it doesn’t include any spaces. Once saved with a different name, the tab at the top will change to the actual filename. Notice that when you subsequently make any changes you’ll see the X on the right side of the tab change to a green circle—this means you have unsaved changes.

After you’ve changed your theme and saved your file as hello, the editor will look similar to Figure 1-5.

We’ll spend a lot of time editing code in Sublime, so we’ll obviously want to make sure we’re saving our changes from time to time. Because I expect that everyone has a little experience with code, I’ll assume that you’ve seen the edit-save-edit process before. On the other hand, there’s a related essential process that many new programmers don’t have experience with, and that’s called version control.

Figure 1-5. Sublime after the theme has been changed to Solarized (light) and the file has been saved as hello

Git has straightforward installers in both Mac OS and Windows. For Windows, we’ll use the msysgit project, which is available on GitHub as shown in Figure 1-6. The installers are still available on Google Code and are linked from the GitHub page. Once you download the installer, double-click it and follow the instructions to get Git on your system.

Figure 1-6. The msysgit home page

For Mac OS, I prefer using the Git OS X installer shown in Figure 1-7. You simply download the prepackaged disk image, mount it, and then double-click the installer. At the time of this writing, the installer says that it is for Mac OS Snow Leopard (10.5), but it worked fine for me on my Mountain Lion (10.8) system.

Figure 1-7. The Git for OS X home page

If you’re using Linux, you can install Git through your package management system.

There are graphical user interfaces to Git, but it’s much more efficient to learn to use it through the command line. Before you learn to do that, however, you’ll have to learn to navigate your filesystem using some basic Unix commands.

Like I mentioned before, I am assuming you have a background in computing and programming so you’ve most likely interacted with a desktop GUI environment. This means that you’ve had to use the desktop environment to explore the files and folders stored on your machine. You typically do this through a filesystem navigator such as Finder for Mac OS or Windows Explorer in Windows.

Navigating your computer’s filesystem from the command line is almost the same as navigating it using your system’s file browser. There are still files, and those files are organized into folders, but we refer to folders as directories. You can easily accomplish all the same tasks that you can accomplish in the file browser: you can move into a directory or out of a directory, see the files that are contained in a directory, and even open and edit files if you’re familiar with Emacs or Vim. The only difference is that there is no continuous visual feedback from the GUI, nor are you able to interact via a mouse.

If you’re in Windows, you’ll do the following in the Git Bash prompt that you installed with the msysgit project described in the previous section. Git Bash is a program that simulates a Unix terminal in Windows and gives you access to Git commands. To fire up the Git Bash prompt, you’ll navigate there via your Start menu. If you’re running Mac OS, you’ll use the Terminal program, which you can find in the Utilities directory of your Applications folder. If you’re using Linux, it depends a bit on the particular flavor you’re using, but there is usually an easily available Terminal program in your applications. The default Mac OS terminal window is shown in Figure 1-8.

Figure 1-8. A default terminal window in Mac OS

Once you open the terminal, you’ll be greeted with a command prompt. It may look different depending on whether you’re using Windows or Mac OS, but it usually contains some information about your working environment. For instance, it may include your current directory, or maybe your username. In Mac OS, mine looks like this:

Last login: Tue May 14 15:23:59 on ttys002
hostname $ _

hostname $ pwd
/Users/semmy

hostname $ ls
Desktop    Downloads  Movies  Pictures
Documents  Library    Music

hostname $ cd Documents

hostname $ ls
Projects

hostname $ pwd
/Users/semmy/Documents

hostname $ cd ..
hostname $ pwd
/Users/semmy
hostname $ ls
Desktop    Downloads  Movies  Pictures
Documents  Library    Music

hostname $ ls
Desktop    Downloads  Movies  Pictures
Documents  Library    Music
hostname $ mkdir Projects
hostname $ ls
Desktop    Downloads  Movies  Pictures
Documents  Library    Music   Projects
hostname $ cd Projects
hostname $ ls
hostname $ pwd
/Users/semmy/Projects

Filesystems and trees

Web development (and programming in general) is a very abstract art form. This roughly means that to do it effectively and efficiently, you’ll need to improve your abstract thinking skills. A big part of thinking abstractly is being able to quickly attach mental models to new ideas and structures. And one of the best mental models that can be applied in a wide variety of situations is a tree diagram.

A tree diagram is simply a way of visualizing any kind of hierarchical structure. And because the Unix filesystem is a hierarchical structure, it’s a good idea to start practicing our mental visualizations on it. For example, consider a directory called Home that contains three other directories: Documents, Pictures, and Music. Inside the Pictures directory are five images. Inside the Documents directory is another directory called Projects.

A tree diagram for this structure might look something like Figure 1-9.

Figure 1-9. A tree diagram representing a file hierarchy

It’s a good idea to keep this mental model in your head while you’re navigating the filesystem. In fact, I would recommend adding an asterisk (or something similar) that denotes your current directory and have that move as you’re moving through the filesystem.

More generally speaking, if you try to attach a tree diagram to any hierarchical structure you’ll most likely find that it’s easier to understand and analyze. Because a large part of being an effective programmer comes from the programmer’s ability to quickly build mental models, it’s a good idea to practice attaching these tree diagrams to real-world hierarchical systems whenever they make sense. We’ll do that in a few instances throughout the rest of the book.

Now that we can navigate the command line, we’re ready to learn how to keep our project under version control with Git.

hostname $ git config --global user.name "Semmy Purewal"
hostname $ git config --global user.email "semmy@semmy.me"

hostname $ pwd
/Users/semmy
hostname $ cd Projects
hostname $ pwd
/Users/semmy/Projects

hostname $ mkdir Chapter1
hostname $ ls
Chapter1
hostname $ cd Chapter1
hostname $ pwd
/Users/semmy/Projects/Chapter1

hostname $ pwd
/Users/semmy/Projects/Chapter1
hostname $ git init
Initialized empty Git repository in /Users/semmy/Projects/Chapter1/.git/

hostname $ ls -a
.   ..   .git

hostname $ ls .git
HEAD       config        hooks   objects
branches   description   info    refs

Determining the status of our repository

Let’s open Sublime Text (if it’s still open from the previous section, close it and reopen it). Next, open the directory that we’ve put under version control. To do this, we simply select the directory in Sublime’s Open dialog box instead of a specific file. When you open an entire directory, a file navigation pane will open on the left side of the editor window—it should look similar to Figure 1-10.

Figure 1-10. Sublime with the Chapter1 directory opened

To create a new file in the Chapter1 directory, right-click (or Command-click on Mac OS) Chapter1 in the file navigation pane and select New File from the context menu. This will open a new file as before, but when you save it, by default it will use the Chapter1 directory. Let’s save it as index.html.

Once it has been named, double-click it and add the line “Hello World!” to the top of the file, as shown in Figure 1-11.

Figure 1-11. Sublime after the index.html file is added, edited, and saved

Let’s see what has happened with our Git repo. Return to your terminal window and confirm you’re in the correct directory:

hostname $ pwd
/Users/semmy/Projects/Chapter1
hostname $ ls
index.html

Now type git status and you’ll see a response that looks something like this:

hostname $ git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   index.html

There’s a lot of information here. We’re most interested in the section labeled Untracked files. Those are the files that are in our working directory, but are not currently under version control.

Notice that our index.html file is there, ready to be committed to our Git repository.

hostname $ git add index.html

hostname $ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#   new file:   index.html
#

hostname $ git commit -m "Initial commit"
[master (root-commit) 147deb5] Initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 index.html

hostname $ git status
# On branch master
nothing to commit (working directory clean)

hostname $ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   index.html
#
no changes added to commit (use "git add" and/or "git commit -a")

hostname $ git add index.html
hostname $ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   index.html
#
hostname $ git commit -m "Add second line to index.html"
[master 1c808e2] Add second line to index.html
 1 file changed, 1 insertion(+)

hostname $ git log
commit 1c808e2752d824d815929cb7c170a04267416c04
Author: Semmy Purewal <semmy@semmy.me>
Date:   Thu May 23 10:36:47 2013 -0400

    Add second line to index.html

commit 147deb5dbb3c935525f351a1154b35cb5b2af824
Author: Semmy Purewal <semmy@semmy.me>
Date:   Thu May 23 10:35:43 2013 -0400

    Initial commit

Saving versus committing

In case it’s confusing, I want to take a moment to clearly differentiate between saving a file (through your text editor) and actually committing a change. When you save a file, you actually overwrite the file on your computer’s disk. That means that unless your text editor offers you some sort of built-in revision history, you can no longer access the old version of the file.

Committing to a Git repository allows you to keep track of all the changes you made since the last time you committed the file. This means that you can always go back to a previous version of the file if you find that you’ve made an unrecoverable mistake in your file’s current state.

At this point, it probably looks as though Git stores your code as a linear sequence of commits. That makes sense right now because you’ve learned a subset of Git that allows you to create a repository of where every commit follows exactly one other commit. We refer to the first commit as a parent commit and the second commit as a child commit. A Git repository with four commits looks similar to Figure 1-12.

It’s worth noting, however, that a commit is a series of instructions for taking your project to the next version. In other words, a Git commit doesn’t actually store the entire contents of your repository in the way that you would if you were to copy a directory to another directory. Instead, it only stores what needs to be changed: for example, a commit might store information like “add a line with Goodbye World" instead of storing the entire file. So it’s better to imagine a Git repository as a sequence of instructions. That’s why we write our commit messages in the present imperative tense—you can think of a commit as a series of instructions for taking your project from one state to the next.

Why does all this matter? Actually, a Git repository may have a much more complex structure. A commit may have more than one child, and—in fact—more than one parent. Figure 1-13 shows an example of a more complex Git repository where both of those are true.

Figure 1-12. A Git repository with four commits

Figure 1-13. A more complex Git repository

Right now, we don’t know any Git commands that will allow us to create a structure like this, but if you continue on in your web app development journey, you’ll have to learn them eventually. The point is that this should motivate you to start picturing your Git repo in a more visual way so that when things do get complex, you don’t get overwhelmed.

Whether you’re on Windows, Mac OS, or Linux, you can install Google Chrome easily by going to the Google Chrome web page. The installation process will, of course, vary, but the instructions are very clear. Once you install Chrome and run it for the first time, it should look something like Figure 1-14.

Figure 1-14. Default Chrome window

In teaching and learning, memorization often has a negative connotation. In my mind, this view is mostly misguided, particularly when it relates to computer programming. If you follow the mindset that “well, I can just look that up when I need it,” you’ll spend more time looking up basic stuff than focusing on the more challenging things that arise. Imagine, for instance, how much more difficult long division would be if you didn’t have your multiplication tables memorized!

With that in mind, I’m going to include a “Memorization” section at the end of the first few chapters that will cover the basic things that you should memorize before moving on to the next chapter. For this chapter, those things are all related to Git and the Unix command line. You should repeatedly do the following things until you can do them without looking at any documentation:

What’s the best way to memorize this sequence of tasks? Simple: do it over and over again. I’ll pile more onto this task throughout the next few chapters, so it’s important to master these steps now.

As I mentioned before, you’ll be spending a lot of time in your text editor, so it’s probably a good idea to move a little beyond the basics. The Sublime website has a great support page that has links to documentation and videos that demonstrate advanced features of the editor. I suggest that you explore the page and see if you can level up your Sublime skills.

Nearly every web developer will eventually have to edit a file on a remote server. This means that you won’t be able to use a text editor that requires a GUI. Emacs and Vim are incredibly powerful editors that make doing so a breeze, but the learning curve on both is relatively steep. If you can find the time, it is really worthwhile to learn the basics of both editors, but it seems to me that Vim has become more common among web developers in recent years (full disclosure: I’m an Emacs user).

The GNU home page has an excellent overview of Emacs, including a tutorial for beginners. O’Reilly also has several books on Emacs and Vim including Learning the vi and Vim Editors by Arnold Robbins, Elbert Hannah, and Linda Lamb and Learning GNU Emacs by Debra Cameron, James Elliott, Marc Loy, Eric S. Raymond, and Bill Rosenblatt.

It would be to your benefit to learn how to do the following things in both editors:

If you take the time to do that, you’ll get a pretty good sense of which editor you would prefer to spend more time with.

The Unix command line takes ages to master, but you’ve learned enough to get started. In my experience, it’s far better to learn things in the context of solving specific problems, but there are a few other basic commands that I use regularly. Using a Google search, learn about some of these common commands: cp, mv, rm, rmdir, cat, and less. These will all come in handy at various times.

Git is an extraordinarily powerful tool—we’ve only barely scratched the surface of its capabilities. Fortunately, Scott Chacon has written Pro Git (Apress, 2009), a great book that covers many aspects of Git in a lot of detail. The first two chapters cover several features that will help you move through this book more efficiently, including reverting to previously committed versions of your repository.

The third chapter of Chacon’s book covers the concept of branching in detail. Branching is a bit beyond the scope of this book, but I hinted at it earlier. I encourage you to explore this topic because the ability to easily and quickly branch your repository is really one of the best features of Git.

GitHub is an online service that will host your Git repositories. If you keep your code open source, it’s free. If you want to create private Git repositories, GitHub’s cheapest plan is about $7 per month. I encourage you to sign up for the free plan and explore storing Git repositories on GitHub.

GitHub’s help page walks you through setting up a GitHub account and connecting it to your Git repository. It also has a ton of useful information on both Git and GitHub in general. Use it to get started.

As you’re typing, one of the things you may notice is that the document consists of two types of content. One type of content is normal text content like “My First Web App” and “Hello, World!” The other type of content, like <html> and <head>, is surrounded by angle brackets, and we refer to these elements as tags. Tags are a form of metadata, and this metadata is used to apply structure to the content of the page.

Fire up Chrome and open the file in your web browser using the Open File option in the File menu. You’ll see something that looks similar to Figure 2-1.

Figure 2-1. hello.html opened in Chrome

Notice that the tags don’t appear, but the other content does. The “My First Web App” content appears as the title of the tab, while the “Hello, World” content appears in the body of the window.

Now, we’ll make a minor modification by adding a paragraph with some lorem ipsum text, which is simply filler text that we can replace with actual copy later. You can cut and paste the text from the Wikipedia page for lorem ipsum:

<!doctype html>
<html>
  <head>
    <title>My First Web App</title>
  </head>

  <body>
    <h1>Hello, World!</h1>

    <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
       tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
       veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
       commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
       velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
       occaecat cupidatat non proident, sunt in culpa qui officia deserunt
       mollit anim id est laborum.</p>

  </body>
</html>

Once we make the changes, we can save the changes to the document. Now we can go back to our browser and reload the page by clicking the circular arrow next to the address bar in Chrome. You should see the body of the browser update with the content, as illustrated in Figure 2-2.

This will be our typical workflow when editing web pages. We’ll open the file in our text editor, make some minor changes, and reload the web browser to see the changes.

Figure 2-2. Modified example1.html opened in Chrome

Comments are a convenient way to annotate our HTML. We start an HTML comment with <!-- and end a comment with -->. Here’s a simple example that’s built on the one in the previous section:

<!doctype html>
<html>
  <head>
    <title>Comment Example</title>
  </head>

  <body>
    <!-- This is the main heading -->
    <h1>Hello World!</h1>

    <!-- This is the main paragraph -->
    <p>I'm a main paragraph, most likely associated with the h1 tag since
       I'm so close to it!</p>
  </body>
</html>

Because computer programs are written for humans to read, it’s always a good idea to annotate some of the more complicated code. You’ll see examples of HTML comments peppered throughout the book and you’ll likely run into commented HTML on the Web.

Now that we’ve seen some examples of basic tags and comments, what other kinds of tags can we include in our markup?

First, we can generalize the <h1> tag by creating <h2>, <h3>, <h4>, <h5>, and <h6> tags. They represent different heading levels, and are usually reserved for important content on the page. The most important heading content should be contained in an <h1> tag, whereas heading content of lesser importance should appear in the others:

<!doctype html>
<html>
  <head>
    <title>Heading Tag Examples</title>
  </head>

  <body>
    <!-- This is the main header -->
    <h1>This is very important!</h1>

    <!--
     This is some content that might be associated with the
     important stuff
    -->
    <p>Important paragraph</p>

    <h2>This is a less important header</h2>
    <p>And here is some less important content</p>

  </body>
</html>

Another important tag in an HTML document is the <a> tag, which stands for anchor and is used to create links. The anchor tags are a unique characteristic of hypertext because they can link to other information, either on the current page or another web page altogether. To use anchor tags, we have to also include an HTML href attribute, which tells the browser where to go when a link is clicked. The href attribute goes inside the opening tag:

<!doctype html>
<html>
  <head>
    <title>Link Examples</title>
  </head>

  <body>
    <!--
     the href attribute tells us where to go when the anchor element
     is clicked
     -->
    <p>Here is a <a href="http://www.google.com">link</a> to Google!</p>
    <p>
      <a href="http://www.example.com">
        And this is a link that is a little longer
      </a>
    </p>
    <p>
      And here is a link to
      <a href="http://www.facebook.com">www.facebook.com</a>
    </p>
  </body>
</html>

When we open this page in the web browser, we’ll get something that looks like Figure 2-3.

Figure 2-3. A page with links using anchor tags

All of the blue underlined text on the page is clickable, and when clicked it will take you to the page specified in the href attribute.

One problem with this example is that it’s using paragraph elements to list content. Wouldn’t it be better if we had a specific tag that represented a list? It turns out that we have two of them! The <ol> tag and the <ul> tag represent ordered lists and unordered lists, respectively. Inside these lists, we have <li> tags that represent list items. In the previous example, it doesn’t look like the order of the links matters much, so perhaps an unordered list would be best:

<!doctype html>
<html>
  <head>
    <title>List Examples</title>
  </head>

  <body>
    <h1>List Examples!</h1>

    <!-- We'll wrap the links in an ul tag -->
    <ul>
      <li>
        Here is a <a href="http://www.google.com">link</a> to Google!
      </li>
      <li>
        <a href="http://www.example.com">
          And this is a link that is a little longer
        </a>
      </li>
      <li>
        And here is a link to
        <a href="http://www.facebook.com">
          www.facebook.com
        </a>
      </li>
    </ul>

    <!-- We can also create an ordered list tag -->

    <h3>How to make an ordered list</h3>
    <ol>
      <li>Start by opening your ol tag</li>
      <li>Then add several list items in li tags</li>
      <li>Close your ol tag</li>
    </ol>
  </body>
</html>

When we refresh our browser, it should look similar to Figure 2-4.

Figure 2-4. A page with an unordered and ordered list

Notice how both lists have bullets at the front of each list item, but the bullets for the ordered list are numeric.

We can generalize a few things from the first few examples that we’ve seen. The first is that all normal text content is wrapped in HTML tags.

Second, you’ll probably notice that we’ve indented HTML tags that are contained in other HTML tags. The reason is that HTML is a hierarchical method of structuring documents. We use indentation as a visual cue to remind us where we are in the hierarchy. That’s why the <head> tag and the <body> tag are indented within the <html> tag, and the <h1> tag and the <p> tags are also indented relative to the <body> tag. We’ve occasionally kept the links on the same line as the content, while other times we’ve broken the line. In HTML, white space doesn’t matter in most cases.

Last, but not least, you’ll see that as we are building an HTML document, we will add or modify a small amount of content, save our progress, then switch to the browser window and reload the page. Because you’ll be doing this so often, it’s a good idea to practice it a few times. To get started, add another few paragraphs of lorem ipsum text to the body of the document, and switch to the browser to reload the page.

Our fake web app is called Amazeriffic, which is a portmanteau of the words amazing and terrific, and despite its silliness, it’s no less ridiculous than many of the company names coming out of Silicon Valley these days. As a product, Amazerrific tracks and categorizes a set of tasks (you can think of it as a to-do list organizer). Later in the book, we’ll actually work on implementing a project like this, but for now we’re going to focus on the front page of the product until we get the hang of HTML. The page that we’ll build looks something like Figure 2-10.

Figure 2-10. The Amazeriffic splash page that we’ll build in this chapter and the next

Remember that HTML is all about the structure of a document. This means that even though we see numerous stylistic elements here (like the various fonts, the colors, and even the layout), it’s best to ignore them for now because, for the most part, it should have no bearing on the HTML. For now we’ll focus exclusively on the structure of the document.

Before we even sit down to code, it’s helpful to see if we can identify the various parts of the structure. Using a pencil and some scratch paper, sketch this layout and label the structural elements as best as you can. If you have no idea what I’m talking about, then draw light boxes around bigger and smaller elements of the page and give them a descriptive name that describes their role in the document.

In Figure 2-11, we see an annotated version of the previous mockup with dashed lines drawn around the elements. We can easily see that some elements are contained inside other elements. This creates a relationship that specifies which elements will be descendants of other elements in the DOM, and this helps us roughly see what the HTML should look like.

Figure 2-11. The Amazeriffic mockup, annotated to illustrate structure

Notice that I could go even further and label the circled parts. For example, it’s relatively obvious where the header, the logo, the navigation links, the footer, the contact information, the sitemap, the main content, the subcontent, and the image are located. These all represent some structural element of the page.

Once we have identified all the structural elements, we’ll need to examine how they fit together. To do this, we can create a tree diagram for the structure that will specify the contents of all the various elements. Figure 2-12 shows what a tree representation of this structure might look like.

Figure 2-12. The Amazeriffic structure in the form of a tree diagram

Once we have a tree representation (either on paper or in our head), it’s pretty easy to code up the HTML if we know the tags that represent these structural content elements. Because we haven’t seen all the tags we’ll need, I’ll introduce them as we go along.

First, before we do anything, we’re going to create a directory to store our project. If you followed the instructions in the first chapter, you already have a Projects directory in your home directory (if you’re in Mac OS or Linux) or your Documents folder (if you’re in Windows). We’ll want to start by navigating to that directory from the Terminal application in Mac OS or from Git Bash in Windows. We’ll use the cd command:

hostname $ cd Projects

Once we’re in that directory, we’ll create a directory for our Amazeriffic project. Which command do we use for that? You’re right! We use the mkdir command:

hostname $ pwd
/Users/semmy/Projects
hostname $ mkdir Amazeriffic

Then we can get some visual feedback that the directory has actually been made by using the ls command, and finally, navigate to that directory with the cd command:

hostname $ ls
Amazeriffic
hostname $ cd Amazeriffic

At this point, we should be in our new project directory (we can confirm that by using the pwd command). The next major thing that we want to do is to put this directory under version control. We use git init to create a Git project:

hostname $ git init
Initialized empty Git repository in /Users/semmy/Projects/Amazeriffic/.git/

Now that we’ve created a directory and put it under version control, we’re ready to start coding! Open up Sublime, and then open the Amazeriffic directory using the keyboard shortcuts described in the previous chapter.

Next, we can create a new HTML document by right-clicking the directory in the navigation pane and selecting New File. This will create an unnamed file that we can rename by simply typing index.html. After it is created and given a name, we can open the file by double-clicking it. Let’s add “Hello World” to the document in order to get some content in it that we can view in the browser.

After having a basic document set up, we can fire up Chrome and open the page. If all goes well, we should see “Hello World” in the browser.

Next, we’ll build a skeleton HTML document to get started. Replace the “Hello World” in your index.html file with the following:

<!doctype html>
<html>
  <head>
    <title>Amazeriffic</title>
  </head>

  <body>
    <h1>Amazeriffic</h1>
  </body>
</html>

Save the file and reload the browser. Once we do that, we should see something that looks similar to Figure 2-13.

Figure 2-13. Amazeriffic, after we add a few basic elements to the page

Once that’s done, we’ll make our first commit. Drop to the command line. First, we’ll check the status of our working directory and then add and commit the index.html file:

hostname $ git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   index.html
hostname $ git add index.html
hostname $ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#   new file:   index.html
hostname $ git commit -m "Add default index.html to repository."
[master (root-commit) fd60796] Add default index.html to the repository.
 1 file changed, 10 insertions(+)
 create mode 100644 index.html

You’ll see that we start by checking the status. That’s a good habit to get into, because visual feedback is always helpful. Among other things, this will tell us if we have inadvertently changed a file that we didn’t intend to change. For now, though, we see that the only file there is index.html.

Add index.html and follow up with another call to git status. That shows us which files will be committed when we run git commit. Finally, we do a git commit along with our message.

Now we’re ready to actually build the structure for the page. If we take a look at the tree, we’ll see that we have a header, a main content section, and a footer. Each of these are children of the body element. It turns out that HTML has a tag representing all three of these sections of a document. The <header> and <footer> tags represent elements that appear at the top and the bottom of a document, and the <main> tag represents the main content area of a document:

<!doctype html>
<html>
  <head>
    <title>Amazeriffic</title>
  </head>

  <body>
    <header>
      <h1>Amazeriffic</h1>
    </header>

    <main>
    </main>


    <footer>
    </footer>
  </body>
</html>

Note that we’ve also moved the <h1> tag containing the Amazeriffic logo inside the header tag. That’s because the logo is a child of the header in our tree diagram.

Next, we’ll see that the upper-right corner of the page has a small navigation section with links to a Sign Up page, a FAQ page, and a Support page. Sure enough, HTML has a tag that supports a navigation element, and it’s called nav. So we’ll add that section to our <header> tag:

    <header>
      <h1>Amazeriffic</h1>
      <nav>
        <a href="#">Sign Up!</a> |
        <a href="#">FAQ</a> |
        <a href="#">Support</a>
      </nav>
    </header>

The links in the nav element are contained in <a> tags. As mentioned previously, <a> tags contain href attributes, which usually contain a link to the page we should be directed to when we click. Because we’re not actually linking anywhere in this example, we’ve used the # symbol as a temporary placeholder for the link.

Because we’ve completed the <header> section, it’s probably a good idea to commit to our Git repository. It might be helpful to do a git status first to see the changed files in our repository. Then we’ll do a git add and a git commit with a meaningful commit message.

Now that we’ve completed the <header> section, we can move on to the <main> section. We’ll see that, like the header, there are two main parts to the structure of the main section. There’s the content on the left side, and then there’s the image that is on the right side. The content on the left side is divided up into two separate sections, so we’ll need to make sure to account for that.

To build out the structure of the content on the left side, we’ll use four new tags. We’ll use two heading tags (<h2> and <h3>), which represent heading text that is less important than an <h1> tag. We’ll also use the <p> tag, which represents paragraph content. In addition, we’ll use the <ul> tag, which represents an unordered list, along with its related <li> tags, which are list items.

And last but not least, we’ll use the <img> tag to include the lightbulb image in our layout. Notice that the <img> tag doesn’t have a closing tag associated with it. That’s because HTML5 includes a set of elements referred to as void elements. Void elements typically do not have content and do not require a closing tag.

We’ll also see that the <img> tag has a required attribute called the alt attribute. This attribute contains a textual description of the image. This is important to make our page accessible by the visually impaired, who often use screen readers when browsing the Internet.

Once we add the structured content to the <main> tag, it will look something like this:

      <h2>Amazeriffic will change your life!</h2>
      <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
         eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>

      <h3>Here's why you need Amazeriffic</h3>
      <ul>
        <li>It fits your lifestyle</li>
        <li>It's awesome</li>
        <li>It rocks your world</li>
      </ul>

      <img src="lightbulb.png" alt="an image of a lightbulb">

When we reload the page in our browser, it should look similar to Figure 2-14.

Figure 2-14. Amazeriffic, after structuring the main element

At this point, it would be a good idea to run your code through the validator and make sure you haven’t inadvertently omitted anything. Once you’re happy with it, make another commit to the Git repository, and we’ll move on to the footer.

The footer contains two main sections just like the other sections. One of the sections includes contact information for the company, and the other section is a set of links that we’ll refer to as a sitemap. Furthermore, the sitemap itself is divided up into two columns.

First of all, there’s no HTML element that represents contact information. That’s okay, because HTML gives us two generic tags called <div> and <span> that allow us to create elements that represent some structure that we define ourselves. We’ll learn the difference between the div and span elements in the next chapter.

In this case, we have two separate structures in the footer: the “Contact” information and the “Sitemap.” Therefore, we’ll create two <div> elements, each of which has a class attribute that specifies the type of the element. At this point, you can think of a class attribute as an attribute that you use to add meaning to the generic <div> and <span> tags.

In addition, we’ll use another <ul> tag to create an unordered list element for the sitemap. The resulting HTML that creates the structure of our footer is as follows:

    <footer>
      <div class="contact">
        <h5>Contact Us</h5>
        <p>Amazeriffic!</p>
        <p>555 Fiftieth Street</p>
        <p>Asheville, NC 28801</p>
      </div>

      <div class="sitemap">
        <h5>Sitemap</h5>
        <ul>
          <li><a href="#">Home</a></li>
          <li><a href="#">About Us</a></li>
          <li><a href="#">Privacy</a></li>
          <li><a href="#">Support</a></li>
          <li><a href="#">FAQ</a></li>
          <li><a href="#">Careers</a></li>
        </ul>
      </div>
    </footer>

Add the footer content to your HTML document, run it through the HTML validator to make sure you haven’t made any mistakes, and commit it to your Git repository.

We’ll revisit this example in Chapter 3, where we’ll style it.

Now that we’ve learned the basics of HTML, we can add a few more steps to our memorization goal. In addition to the five steps mentioned in the previous chapter, you should add the following to your practice:

Draw a tree diagram for the following HTML document. We’ll also use this HTML document for practice problems at the end of Chapter 3 and Chapter 4:

<!doctype html>
<html>
  <head>
  </head>

  <body>
    <h1>Hi</h1>
    <h2 class="important">Hi again</h2>
    <p class="a">Random unattached paragraph</p>


    <div class="relevant">
      <p class="a">first</p>
      <p class="a">second</p>
      <p>third</p>
      <p>fourth</p>
      <p class="a">fifth</p>
      <p class="a">sixth</p>
      <p>seventh</p>
    </div>
  </body>
</html>

In Amazeriffic’s navigation bar, there is a dead link for a Frequently Asked Questions page. Create a page that follows exactly the same style for the header and footer, but has a list of questions and answers as its main content. Use lorem ipsum text as a placeholder (unless you actually want to come up with questions and answers).

Save the file as faq.html. You can link to the page by filling out the href attribute in its associated <a> tag—set it to faq.html. If you include the two pages in the same directory, you should be able to click from the main splash page to get to the FAQ page. Similarly, you can link back to index.html from faq.html.

In Chapter 3 we’ll style this page.

Throughout this book, I’ll point you to the Mozilla Developer Network documentation for more information on certain topics. Its site includes a wonderful overview of HTML. I encourage you to take a look for more in-depth documentation and advanced features.

A CSS file is a collection of rulesets and a ruleset is simply a collection of style rules that are applied to some subset of elements in the DOM (which you will recall is the hierarchical object defined by the HTML document). A ruleset consists of a selector (which we can think of as a tag name for now), an opening curly brace, a list of rules, and a final closing curly brace. Each rule consists of a specific property, followed by a colon, followed by a value (or a list of values separated by spaces), followed by a semicolon:

body {
    width: 800px;
    background: lightcyan;
    color: #ff0000;
}

This is an example of a ruleset that gets applied to the body element in the DOM. In this case, the selector is “body,” which is just the name of the HTML element to which we want to apply the style. These rules will apply to all of the content of the body element, as well as any elements contained in the body element. The ruleset consists of three rules, one specifying the value for the width property, one specifying the value for the background property, and one specifying a value for the color property.

An experienced CSS developer has a solid knowledge of the types of properties that can be set for a particular element, and the types of values that each property accepts. Several properties, like background and color, can be used to style most HTML elements.

Our CSS code can also include comments. Like HTML comments, CSS comments are code annotations that are completely ignored by the browser. For example, we can insert comments in the previous CSS ruleset:

/* Here we are styling the body */
body {
    width: 800px;          /* Set the body width to 800 pixels */
    background: lightcyan; /* Set the background to a light bluish color */
    color: #ff0000;        /* Set the foreground color to red */
}

Some people will suggest that you be very liberal with your comments in all programs. I tend to think that you should let your code speak for itself as much as possible, and minimize places where comments are necessary. In fact, experienced CSS developers would find the preceding comments to be superfluous, because once you know a little these types of comments become redundant. On the other hand, there are times when it won’t be obvious what your code is supposed to be doing, and in those cases it’s a good idea to annotate it.

If you’re just starting out with CSS, I always recommend erring on the side of more comments. I’ll use comments liberally for most of the remainder of this chapter to make things easier to understand.

For the most part, HTML elements are displayed in one of two ways. The first way is inline, which applies to elements that have the type a or span, for example. This means (among other things) that the content will appear on the same line as the surrounding content:

<div>
  This is a paragraph and this <span>word</span> appears inline. This
  <a href="http://www.example.com">link</a> will also appear inline.
</div>

If we add this code to the <body> tag of the index.html file, the page will render similar to the image in Figure 3-3.

It’s actually more common for elements to be block elements instead of inline elements. This means that the content contained inside the element will appear on a new line outside of the normal flow of text. Block elements that we’ve seen include the p, nav, main, and div elements:

<div>
  This is a paragraph and this <div>word</div> appears inline. This
  <a href="http://www.example.com">link</a> will also appear inline.
</div>

This code will look different, as illustrated in Figure 3-4.

Figure 3-3. An example of inline elements within a block element

Figure 3-4. An example of block elements within a block element

Both block style elements and inline elements have background and color properties. But block style elements have three other properties that come in very handy when styling the page with custom layouts. They are padding, border, and margin.

The padding property represents the spacing between the content of the element and the border, and the margin is the spacing between the element and its surrounding element. The border property represents the space between the padding and the margin. This is illustrated in Figure 3-5.

Figure 3-5. The margin, border, and padding of a block DOM element

Here’s a simple example that you can use to manipulate the padding, border, and margin of a few different elements. The first file is margin_border_padding.html:

<!doctype html>
<html>
  <head>
    <title>Chapter 3 -- Margin, Border, and Padding Example</title>
    <link href="margin_border_padding.css" rel="stylesheet" type="text/css">
  </head>

  <body>
    <div>
      <p>THIS IS A PARAGRAPH CONTAINED INSIDE A DIV</p>
    </div>
  </body>
</html>

And here is margin_border_padding.css, which is referenced in the preceding HTML file. You can create these files in the same directory in Sublime, and then open the margin_border_padding.html file in Chrome:

body {
  background: linen;
  width: 500px;
  margin: 200px auto;
}

div {
  border: 5px solid maroon;
  text-align: center;
  padding: 5px;
}

p {
  border: 2px dashed blue;
}

If you typed everything in correctly, the page should look similar to Figure 3-6.

Figure 3-6. A margin/padding/border example to explore

You can see that both elements (the div and the p) are block elements so they each have their own border, margin, and padding properties. If you haven’t already done it, take this opportunity to create the HTML and CSS just shown. Then spend some time changing the padding, border, and margin properties of each element to see how they affect the way the page is displayed.

In Chapter 2, we saw that we can add a class attribute to <div> tags to differentiate between them. It turns out that we can add a class to any DOM element. For example, we can rewrite the previous HTML to look as follows:

<body>
  <h1>Hello World!</h1>

  <p class="first">This is a paragraph.</p>

  <p class="second">This is a second paragraph.</p>
</body>

Now we can select the specific paragraph tag by its class name:

h1 {
    background: black;
    color: white;
}

p.first {
    color: red;
    margin: 10px;
    padding: 20px;
}

In this example, the p.first ruleset will only be applied to the first paragraph element. If the class only appears on a certain type of element (which is usually the case), we can omit the tag name and simply use the class:

.first {
    color: red;
    margin: 10px;
    padding: 20px;
}

In the previous chapter, we saw that we could create clickable DOM elements with the <a> tag:

<body>
  <a href="http://www.example.com">Click Me!</a>
</body>

The a element can be styled just like any other DOM element via CSS. For example, we can create a CSS file that changes the color of all links:

a {
    color: cornflowerblue;
}

It’s often useful, however, to have links with a different color depending on whether or not the user has already clicked them. CSS allows us to change the color of visited links by adding another ruleset:

a {
    color: cornflowerblue;
}

a:visited {
    color: tomato;
}

In this example, visited is an example of a CSS pseudoclass on the a element. It almost behaves just like a normal class in that we can style elements that have the class in the same way as a normal class. The main difference is that the browser actually implicitly adds the class for us.

One common use case for CSS pseudoclasses is changing the way a link is displayed when a user hovers over it. This can be achieved by using the hover pseudoclass on an a element. In the following example, we modify the previous example so that the link is underlined only when the user is hovering over it:

a {
    color: cornflowerblue;
    text-decoration: none; /* remove the default underline */
}

a:visited {
    color: tomato;
}

a:hover {
    text-decoration: underline;
}

As our tree diagram for the DOM gets more complicated, it becomes necessary to create more complicated selectors. For example, consider this HTML:

<body>
  <h1>Hello World!</h1>

  <div class="content">
    <ol>
      <li>List Item <span class="number">first</span></li>
      <li>List Item <span class="number">second</span></li>
      <li>List Item <span class="number">third</span></li>
    </ol>

    <p>This is the <span>first</span> paragraph.</p>

    <p>This is the <span>second</span> paragraph.</p>
  </div>

  <ul>
    <li>List Item <span class="number">1</span></li>
    <li>List Item <span class="number">2</span></li>
    <li>List Item <span class="number">3</span></li>
  </ul>
</body>

This HTML has two lists, several paragraphs, and several list items. We can easily select and style general elements as we’ve discussed previously. For example, if we want to create a rounded border around the ordered list (ol) element, we can apply the following ruleset:

ol {
    border: 5px solid darksalmon;
    border-radius: 10px;
}

Now suppose we wanted to make it so the list items in the ordered list are brown. To do that, our immediate intuition might be to do the following:

li {
    color: brown;
}

But this will change the li elements in both the unordered list and the ordered list. We can get more specific with our selector by only selecting the li elements in the ordered list:

ol li {
    color: brown;
}

If there are several ordered lists on the page, we may want to get even more specific and select only the li elements that are descendants of the content div element:

.content li {
    color: brown;
}

Now suppose we want to set the background of the first li elements in both lists to yellow. It turns out that there’s a pseudoclass representing elements that are a first-child of their parents:

li:first-child {
    background: yellow;
}

Likewise, we can select the elements that are second, third, fourth, etc., children by using the nth-child pseudoclass:

li:nth-child(2) {
    background: orange;
}

What happens when two different rulesets use selectors that target the same element in CSS? For example, consider a p element with class greeting:

<p class="greeting">Hello, Cascading Rules!</p>

Now suppose that we have two rules that select that element and apply different styles:

p {
    color: yellow;
}

p.selected {
    color: green;
}

Which rule gets applied to the class above? It turns out that there are a set of cascading rules that browsers apply when conflicts arise. In this case, the more specific rule (the class) takes precedence. But what happens if we do something like the following?

p {
    color: yellow;
}

p {
    color: green;
}

In this case, the cascading rules specify that the ruleset that appears later in the CSS list will be applied. So in this case, the paragraph(s) will be green. If we swapped the rules, the paragraph(s) would be yellow.

If you haven’t noticed by now, descendants inherit properties of their ancestors. What this means is that if we create a style on an element, all descendants of that element in the DOM will also have that style unless it is overridden by another ruleset that targets that element. So, for example, if we select the body and change the color property, all elements that are descendants of the body (which means all elements appearing on the page) will inherit that color. This is an essential part of CSS and this is why it’s helpful to maintain a visualization of the DOM hierarchy in your head while styling elements:

body {
    background: yellow;
}

/**
 * Since h1 is a descendant of the body tag
 * it will have a yellow background.
 */
h1 {
    color: red;
}

/**
 * h2 is also a descendant of body, but
 * we'll override the background so it's
 * not yellow
 */
h2 {
    background: green;
}

Though most CSS properties work this way, it’s worth noting that not all properties are inherited by default. The most notable noninherited properties are related to block-style elements (the margin, padding, and border rules aren’t inherited from ancestors):

body {
    margin: 0;
    padding: 0;
}

/**
 * h1 will not inherit the margin and padding of the body,
 * even if we don't specify an alternative
 */
h1 {

}

One interesting issue can arise when building layouts using floating elements. Here is a slightly different HTML document. This time, our goal is to set up the navigation on the left side with a footer underneath both columns:

<body>
  <nav>
    <p><a href="link1">link1</a></p>
    <p><a href="link2">link2</a></p>
    <p><a href="link3">link3</a></p>
    <p><a href="link4">link4</a></p>
  </nav>

  <main>
    <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
       eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim
       ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut
       aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit
       in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
    </p>
  </main>

  <footer>
    <p>This is the footer</p>
  </footer>
</body>

The following CSS floats the nav element to the left and clears out the default margins and paddings using the universal selector, which selects all elements in the DOM. It also sets the background of the elements to various distinguishable shades of gray:

* {
    margin: 0;
    padding: 0;
}

nav {
    float: left;
    background:darkgray;
}

main {
    background:lightgray;
}

footer {
    background:gray;
}

When we render this document using this stylesheet, we’ll see something similar to Figure 3-11.

Figure 3-11. Notice that the footer is below the main section, instead of below everything

Note that the footer is actually on the right of the layout, underneath the main section. We’d like the footer to be underneath both elements. This is what the clear property does for us. We can force the footer element to be underneath a floating element on the right, the left, or under both the right and left floating elements by specifying the clear property. So we can change the footer CSS as follows:

footer {
    background:gray;
    clear: both;      /* or we can just use 'clear: left' in this case */
}

And this will render as shown in Figure 3-12.

Now the footer is underneath the floating element, as desired.

Floats tend to be one of the more confusing aspects of CSS for beginners, so I encourage you to spend some time experimenting and building layouts.

Now let’s examine the style for Amazeriffic. Notice that the content is horizontally aligned in two columns. The first column takes up about two-thirds of the content area, while the second column takes up about one-third of the content area. Next, notice that the content is vertically aligned in about three rows. This defines a styling grid over the content, which is one basic approach to design layouts.

Another aspect of the design that’s hard to get across in a book is that it’s a fixed width design. This means that as we resize our browser window, the content of the page remains centered at the same width regardless. Figure 3-21 and Figure 3-22 show Amazeriffic in two browser windows of different sizes.

Figure 3-21. Amazeriffic in a 1,250 × 650 browser window

This means the design is not responsive, which is a modern approach to CSS layout that allows the layout to rearrange itself depending on the width of the browser. This is important when designing for the Web, because many people will view the design on a mobile phone or tablet. We’re not going to spend much time on responsive design here, but you’ll have the opportunity to try a few tools that simplify the responsive design process in the exercises at the end of this chapter.

Figure 3-22. Amazeriffic in an 800 × 575 browser window

Our goal is to build this two-column, fixed width design using CSS. To start with, we’ll need to make it so that the rows (which in this case are our header, main, and footer elements) have the fixed width property. The first thing that we can do to assist us in this is to create a ruleset for all of these elements. In our style.css file, we’ll add a ruleset that looks as follows:

header, main, footer {
    min-width: 855px;
}

The min-width property makes it so that if the browser is resized to a viewport smaller than 855 px, the remaining part of the page will be hidden from view. Try it out.

Next, notice that the footer has a yellowish color that should fill the bottom of the page as the browser window is expanded vertically. This means that the yellow color will have to be the background color of the entire page, and we’ll need to change the color of the header and the main elements to white later.

We can add a rule to the body that makes the background of the image that yellow color in the body ruleset. Note that even though I added the previous ruleset first, I’ll still add the body ruleset above it in the style.css file. That’s because it comes prior to the header, main, and footer elements in the HTML file. Keeping the locations (relatively) consistent between these two files makes it easier to find issues and make changes:

body {
    background: #f9e933;
}

header, main, footer {
    min-width: 855px;
}

Now we’ll see that the entire page is the off-yellow color, so we’ll change the backgrounds of the header and main elements to be white. To do this, we’ll add two new rulesets for the header and main elements in addition to the one that contains the min-width rule. We’ll separate them because we’ll want to add different styling rules to each as we move forward:

header {
    background: white;
}

main {
    background: white;
}

So now we’ve got things looking similar to Figure 3-23.

Now that we have some basic styling set up, it’s probably a good idea to commit the changes to your Git repository. Start by checking the status. The only file that should have changed is style.css. Stage that file (with the add command) and then commit the change with a meaningful commit message.

Figure 3-23. Amazeriffic after some (very) basic styling

Next, we’d like the following things to happen. We’d like to have the content centered and fixed at 855 px wide. We’re choosing 855 px because we’d like to have the number of pixels divisible by 3 (because the columns are about two-thirds and one-third wide). Because 855/3 is 285, this gives us the ability to work with whole numbers.

Here’s a potential approach to solving this problem. We could add a max-width rule to the ruleset styling the header, main, and footer, set the width of the body to 855px, and then set the margin on the body to auto. Before moving on, try that and see what happens.

If you actually did it, you probably realized that the header and main content areas are now not stretching to fit the full size of the page and so the background color is filling the spaces to the left and right. This is not what we want.

How do we fix this? This is a case where we’ll want to add a div element to the DOM so we can style the elements independently. We want the header and main elements to span the entire width of the page, but the content contained inside to be 855 px. So we’ll create a container class inside those two elements to hold the content. Go ahead and modify the HTML so that the header, main, and footer elements contain a class called container, which contains the content elements. For example, here’s what we would do with the header div:

    <header>
      <div class="container">
        <h1>Amazeriffic</h1>
        <nav>
          <a href="#">Sign Up!</a> |
          <a href="#">FAQ</a> |
          <a href="#">Support</a>
        </nav>
      </div>
    </header>

Now we can make the container content have a max width of 855 px and an automatic margin. When we’re finished, our rulesets should look something like this:

body {
    background: #f9e933;
}

header, main, footer {
    min-width: 855px;
}

header .container, main .container, footer .container {
    max-width: 855px;
    margin: auto;
}

header {
    background: white;
}

main {
    background: white;
}

Now as we resize our browser, our content will remain at a fixed width! This is a good point to drop to the terminal window and commit your changes to your Git repository. This time you have modified two files, so you’ll need to add both to your Git repository before committing.

The next thing that we want to do is to create the columns in the content elements. To do this, we’ll float the content that is in the right column to the right, and specify the widths for the right column to be 285 px and the width of the left column to be 570 px. We’ll also set the overflow property to auto so that the element won’t shrink to zero when we float both children elements.

When we finish the header rulesets, they will look something like this:

header {
    background: white;
    overflow: auto;
}

header h1 {
    float: left;
    width: 570px;
}

header nav {
    float: right;
    width: 285px;
}

The header is a little unique because it only contains two child elements—the h1 element and the nav element. This is not true of the main and footer elements. If you’re thinking about this correctly, you’ll most likely need to add additional divs to both of them in order to package the floating left and right content into a single element. And on the right side of the footer, you’ll need to create a subleft/-right layout to style the sitemap. This is by design—you should be able to do this with the skills you have learned in this chapter.

I would work on one section at a time: get the header looking correct, then get the main content area looking correct, and then get the footer looking correct. You should make intermediate commits to your Git repository. I would also periodically run your code through CSS Lint (and the HTML validator, if you’re modifying the HTML) to make sure you don’t have any potential problems.

When we finish with this section, we’ll have something that looks like Figure 3-24.

Figure 3-24. Amazeriffic after a little more styling

Once your page looks like this and you’ve identified any potential problems by running your CSS through CSS Lint, it is a good time to make another commit to your Git repository.

Next, we’ll add two Google Fonts. For this example, I’ve used the Ubuntu and the Droid Sans fonts. The header tags (<h1>, <h2>, <h3>, and <h4>) are all styled with the Ubuntu font, and the rest of the page content is styled with Droid Sans. This will require us to add two link tags to our HTML file and then rules in the CSS.

After you have the fonts set correctly, commit the changed files to your Git repository. Once you do that, set up a base font size of 100% and modify the font sizes of the elements in an attempt to get them looking as close as possible to the original mock-up image.

After getting the font sizes looking correct, validate your HTML and run your CSS through Lint to try to identify problems. Once you do that, commit the changes to your Git repository.

Finally, you’ll need to add padding and margins to get everything lined up and spaced correctly. This will require experimenting with the margins and padding on various elements. I encourage you to do that in the Chrome Developer Tools. You’ll also need to style the links on the page. All of the links are red and not underlined unless the cursor is hovering over them. That will require you to manipulate the hover pseudoclass of the a elements.

We’ll start by adding a few more steps to our practice. Remember, your goal is to memorize how to do this along with the previous steps listed in the previous chapters:

Type up the following HTML document and save it in a file called selectorpractice.html:

<!doctype html>
<html>
  <head>
  </head>

  <body>
    <h1>Hi</h1>
    <h2 class="important">Hi again</h2>
    <p class="a">Random unattached paragraph</p>


    <div class="relevant">
      <p class="a">first</p>
      <p class="a">second</p>
      <p>third</p>
      <p>fourth</p>
      <p class="a">fifth</p>
      <p class="a">sixth</p>
      <p>seventh</p>
    </div>
  </body>
</html>

Next, attach a CSS file via a link. In the CSS, add a single selector:

* {
  color: red;
}

This changes the text color of every element to red. We’ll use this file to practice our CSS selectors. Replace the * with a selector that selects the following element(s) and confirm that only the selected elements change to red:

The Mozilla developer documentation has a great tutorial on selectors. Their tutorial covers much more than we’ve seen here. Once you’re comfortable with the selectors I’ve introduced, I encourage you to read it.

If you completed the questions at the end of Chapter 2, you built a FAQ page for Amazeriffic. Link the style.css file to faq.html and add additional style rules to style the content portion of the page. If the structure of the header and footer is the same, you shouldn’t have to modify those rules. You’ll simply add additional rules for the main section to style the FAQ page.

In this chapter, I covered CSS’s cascading rules at a very high level. I think that they are pretty intuitive for the most part. On the other hand, knowing the rules in detail is often helpful when troubleshooting CSS issues. The W3C has the rules clearly specified. I encourage you to read them and commit them to memory, particularly if you find yourself doing a lot of work with CSS.

One major topic relating to CSS that we haven’t learned is responsive design. A design is said to be responsive if it changes its layout based on the height and width of the browser in which it is displayed. This is important in this day and age because of the number of people who view web applications and web pages on mobile phones and tablets.

It’s possible to build responsiveness into your CSS using media queries. But this goes a little beyond the scope of this book. You can read about them on Mozilla’s developer website. I encourage you to do so.

In addition, several CSS frameworks are available that allow you to build responsive designs with minimal work. I’ve used both Twitter Bootstrap and Zurb’s Foundation. If you’ve enjoyed working with layouts and CSS in this chapter, you may want to read the documentation for both of these frameworks and try to rebuild the Amazeriffic layout as a responsive design using one of them. These two frameworks are also great to keep in mind as starting points for future projects.

Let’s take a quick look at the user interface before we get started. It is shown in Figure 4-2.

Figure 4-2. The user interface for our first interactive app

You’ll see that the structure consists of three primary elements: the header, the footer, and main. With this in mind, we can modify our HTML to outline our user interface:

<!doctype html>
<html>
  <head>
    <title>A Simple App</title>

    <link href="style.css" rel="stylesheet" type="text/css">
  </head>

  <body>
    <header>
    </header>

    <main>
      <!-- note that we use a dash here for our CSS class name
           that contains multiple words, that's a CSS convention -->
      <section class="comment-input">
      </section>

      <section class="comments">
      </section>
    </main>

    <footer>
    </footer>

    <script src="http://code.jquery.com/jquery-2.0.3.min.js"></script>
    <script src="app.js"></script>
  </body>
</html>

Once you modify your HTML to look similar to the preceding code, commit it to your Git repository. Next, fill in the header and footer elements, along with the primary part of the main content on the left side, to correspond with the design in Figure 4-2. Hopefully you can see that some of the sections will have an <h1>, <h2>, or <h3> tag along with some content. Add those now.

For the comment-input section, we’ll use a new HTML tag: <input>. The input element represents an input text box, and doesn’t require a closing tag. Add an empty <input> tag to the comment-input section. You can also add the paragraph with our “Add Your Comment:” prompt:

<section class="comment-input">
  <p>Add Your Comment:</p>
  <input type="text">
</section>

In the .comments section, add a few example comments that will simply be paragraph tags. This will help us with the styling. So, for example, we may modify our comments section to look something like this:

<section class="comments">
  <p>This is the first comment!</p>
  <p>Here's the second one!</p>
  <p>And this is one more.</p>
  <p>Here is another one</p>
</section>

Finally, we’ll add a button element labeled with a + character. Although we haven’t seen the button element yet, there’s nothing particularly special about it until we attach a JavaScript behavior to it. To add a button, we’ll add the <button> tag immediately following the <input> tag. The code contained in my comment-input section looks something like this:

<section class="comment-input">
  <p>Add Your Comment:</p>
  <input type="text"><button>+</button>
</section>

Once we have the structure defined, let’s commit it to our Git repository and move on to styling the page.

The style consists of a few simple things. First, it might be helpful to use a reset, but don’t feel obligated to do so for this example. At minimum you’ll want to keep the simple CSS starting point where we’ve zeroed out the default margin and padding.

The width of the body is 855 pixels in this example, with the left column taking up a third of that. The other two-thirds of the body consists of the comments.

One interesting aspect of the comments section is that we’ve alternated colors for comments. In other words, the even-numbered comments are one color, and the odd-numbered comments are another. We can achieve this effect using pure CSS—we’ll simply use the nth-child pseudoclass along with the even or odd value. For example, if we want to alternate the colors lavender and gainsboro, we can create CSS rulesets that look like this:

.comments p:nth-child(even) {
    background: lavender;
}

.comments p:nth-child(odd) {
    background: gainsboro;
}

If you’ve added some example comments, you should see the background colors alternate once you add this ruleset to the CSS. Notice that we’ve also given our comments a slight border-radius to make them have rounded edges.

Other than that, the rest of this layout should follow previous examples pretty closely. Finish styling the interface as best as you can and commit your code to the Git repository so we can move on to making it interactive. If you have trouble, you can see it in our GitHub repository.

Now we’re ready to work on the interactivity. We’ll build this example step by step, making Git commits along the way.

var main = function () {
    "use strict";

    $(".comment-input button").on("click", function (event) {
        console.log("Hello World!");
    });
};

$(document).ready(main);

var main = function () {
    "use strict";

    $(".comment-input button").on("click", function (event) {
        $(".comments").append("<p>this is a new comment</p>");
    });
};

$(document).ready(main);

var main = function () {
    "use strict";

    $(".comment-input button").on("click", function (event) {
        var $new_comment = $("<p>");

        $new_comment.text("this is a new comment");
        $(".comments").append($new_comment);
    });
};

$(document).ready(main);

var $new_comment = $("<p>").text("this is a new comment");

$(".comment-input input");

$(".comment-input input").val();

var main = function () {
    "use strict";

    $(".comment-input button").on("click", function (event) {
        var $new_comment = $("<p>"),
            comment_text = $(".comment-input input").val();

        $new_comment.text(comment_text);

        $(".comments").append($new_comment);
    });
};

$(document).ready(main);

var $new_comment = $("<p>").text($(".comment-input input").val());

.comment_input span:hover {
    cursor: pointer;
}

$(".comment-input button").on("click", function (event) {
    var $new_comment;

    if ($(".comment-input input").val() !== "") {
        $new_comment = $("<p>").text($(".comment-input input").val());
        $(".comments").append($new_comment);
    }
});

$(".comment-input input").val("");

$(".comment-input button").on("click", function (event) {
    var $new_comment;

    if ($(".comment-input input").val() !== "") {
        var $new_comment = $("<p>").text($(".comment-input input").val());
        $(".comments").append($new_comment);
        $(".comment-input input").val("");
    }
});

$(".comment-input input").on("keypress", function (event) {
    console.log("hello world!");
});

$(".comment-input input").on("keypress", function (event) {
    console.log("this is the keyCode " + event.keyCode);
});

$(".comment-input input").on("keypress", function (event) {
    if (keyCode === 13) {
        console.log("this is the keyCode " + event.keyCode);
    }
});

$(".comment-input input").on("keypress", function (event) {
    var $new_comment;

    if (event.keyCode === 13) {
        if ($(".comment-input input").val() !== "") {
            var $new_comment = $("<p>").text($(".comment-input input").val());
            $(".comments").append($new_comment);
            $(".comment-input input").val("");
        }
    }
});

$(".comment-input button").on("click", function (event) {
    var $new_comment;

    if ($(".comment-input input").val() !== "") {
        $new_comment = $("<p>").text($(".comment-input input").val());
        $new_comment.hide();
        $(".comments").append($new_comment);
        $new_comment.fadeIn();
        $(".comment-input input").val("");
    }
});

var main = function () {
    "use strict";

    $(".comment-input button").on("click", function (event) {
        var $new_comment;

        if ($(".comment-input input").val() !== "") {
            $new_comment = $("<p>").text($(".comment-input input").val());
            $new_comment.hide();
            $(".comments").append($new_comment);
            $new_comment.fadeIn();
            $(".comment-input input").val("");
        }
    });

    $(".comment-input input").on("keypress", function (event) {
        var $new_comment;

        if (event.keyCode === 13) {
            if ($(".comment-input input").val() !== "") {
                $new_comment = $("<p>").text($(".comment-input input").val());
                $new_comment.hide();
                $(".comments").append($new_comment);
                $new_comment.fadeIn();
                $(".comment-input input").val("");
            }
        }
    });
};

$(document).ready(main);

var main = function () {
    "use strict";

    var addCommentFromInputBox = function () {
        var $new_comment;

        if ($(".comment-input input").val() !== "") {
            $new_comment = $("<p>").text($(".comment-input input").val());
            $new_comment.hide();
            $(".comments").append($new_comment);
            $new_comment.fadeIn();
            $(".comment-input input").val("");
        }
    };

    $(".comment-input button").on("click", function (event) {
        addCommentFromInputBox();
    });

    $(".comment-input input").on("keypress", function (event) {
        if (event.keyCode === 13) {
            addCommentFromInputBox();
        }
    });
};

$(document).ready(main);

Before we begin, let’s start by discussing a little more about our workflow. Generally, the client-side portion of our application can span multiple HTML, CSS, and JavaScript files. Therefore, it’s often helpful to keep those things organized in a meaningful way.

From here on out, we’ll keep all of our HTML files in the root of our project directory, and then we’ll have three subdirectories called stylesheets, images, and javascripts. We’ll make sure that their content appropriately reflects their names.

This changes things slightly when we’re linking stylesheets or importing scripts. Here’s an example of how this change affects our HTML:

<!doctype html>
<html>
  <head>
    <link href="stylesheets/reset.css" rel="stylesheet">
    <link href="stylesheets/style.css" rel="stylesheet">
  </head>

  <body>
    <script src="http://code.jquery.com/jquery-2.0.3.min.js"></script>
    <script src="javascripts/app.js"></script>
  </body>
</html>

Note that we’ve had to explictly qualify the location of our script and CSS files by prepending them with a forward slash and the directory name.

Before we start typing in real code, it’s probably good to start with a discussion of JavaScript comments. Just like in HTML and CSS, we can put comments in our JavaScript to annotate our code for human readers. There are two types of comments: a single-line comment and a multiline comment. Single-line comments are created by using two forward slashes next to each other, and multiline comments look just like CSS comments:

// this is a single-line comment, which runs to the end of the line

var a = 5; // this is a single-line comment following some actual code

/* This is a multiline comment that will run until
   we close it. It looks like a CSS comment */

As we’ve seen in the previous example, jQuery selectors are very similar to CSS selectors. In fact, we can use any CSS selector as a jQuery selector. So, for example, the following jQuery selectors select exactly what we’d expect:

$("*");              // selects all elements in the document
$("h1");             // selects all of the h1 elements
$("p");              // selects all of the p elements
$("p .first");       // selects all paragraph elements with the class 'first'
$(".first");         // selects all elements with the class 'first'
$("p:nth-child(3)"); // selects all paragraph elements that are the third child

It turns out that jQuery selectors aren’t identical to CSS selectors in all cases. In fact, jQuery adds a rich set of pseudoclasses and pseudoelements that are not currently available in CSS. Additionally, certain valid CSS identifiers have to be represented differently when used in jQuery (special characters such as . must be escaped by two backslashes). But for our purposes, we are going to think of jQuery selectors as CSS selectors that return DOM elements that we can manipulate in our JavaScript. If you’re interested in learning more, you can check out the jQuery selector documentation.

Once we’ve successfully used selectors to add elements to the DOM, it’s likely that we’re going to want to manipulate them in some way. jQuery makes that pretty easy.

Adding elements to the DOM

To get started, it’s helpful to remember our tree mental model for the DOM. For instance, consider this HTML snippet:

<body>
  <h1>This is an example!</h1>
  <main>
  </main>

  <footer>
  </footer>
</body>

Note that our main and footer elements are empty. We can draw a tree diagram as shown in Figure 4-3.

Figure 4-3. A tree diagram of the DOM before any manipulation is done with jQuery

To create an element, we use the same $ operator that we use to select an element. Instead of sending in a selector, however, we send in the tag representing the element we’d like to create:

// By convention, I start jQuery object variables with a $
var $newUL = $("<ul>"); //create a new li element
var $newParagraphElement = $("<p>"); // create a new p element

Once we’ve created an element, we can add things to it, including other HTML elements. For example, we can add text to our p element like this:

$newParagraphElement.text("this is a paragraph");

After we execute that code, our paragraph DOM element will be equivalent to the following HTML:

<p>this is a paragraph</p>

The ul and the p elements that we’ve created are not part of the DOM that appears on the page yet, so our tree diagram would have those new elements floating off in space, but referenced by their associated jQuery variables. This is illustrated in Figure 4-4.

Figure 4-4. After the ul and p elements are created, but not yet attached to the DOM

We can add it to the page by selecting the element to which we want to append it, and then calling the append function on the jQuery object. For example, if we want to add this element as a child of the footer element, we can do the following:

$("footer").append($newParagraphElement);

Now our content should appear in the footer because the element is connected to the tree diagram! It looks something like Figure 4-5.

Figure 4-5. The DOM, after the p element is added to the footer

We can actually build far more complicated DOM structures before we make them appear on the page. For example, we can add li elements to the ul element we created previously:

// we can chain our creation and call to add the text
var $listItemOne = $("<li>").text("this is the first list item");
var $listItemTwo = $("<li>").text("second list item");
var $listItemThree = $("<li>").text("OMG third list item");

// now we'll append these elements to the ul element we created earlier
$newUL.append($listItemOne);
$newUL.append($listItemTwo);
$newUL.append($listItemThree);

At this point, we have a new subtree disconnected from the rest of the tree. It looks something like Figure 4-6.

Figure 4-6. The DOM, with an unconnected subtree that represents a ul element

Now suppose we want to attach this subtree to the body as part of the main element. We follow the same pattern as before, but we only have to attach the root of our subtree!

$("main").append($newUL);

Now our DOM tree looks like Figure 4-7.

Figure 4-7. The DOM, with an unconnected subtree that represents a ul element

jQuery provides some flexibility in adding things once we have a DOM element selected. For instance, we can prepend elements instead of appending them, which makes them the first child of the parent node:

var $footerFirstChild = $("<p>").text("I'm the first child of the footer!");
$("footer").prepend($footerFirstChild);

In addition, we can use appendTo or prependTo to change the way our code reads:

// this is equivalent to the previous line
$footerFirstChild.appendTo($("footer"));

Don’t forget that we can also use the Elements tab in the Chrome Developer Tools to confirm that our DOM is updated as described in the previous section.

// remove the first list item from
// the list we created previously
$("ul li:first-child").remove();

// remove all children from the
// list we created previously
$newUL.empty();

// this will remove the footer paragraph from the DOM.
$("footer p").fadeOut();

In the first example of this chapter, we saw how to process both the click event and the keypress event. In general, we can process any event using the on pattern. For example, we can respond to the dblclick event, which is triggered when a user double-clicks:

$(".button").on("dblclick", function () {
    alert("Hey! You double-clicked!");
});

In general, this style of programming is called event-driven or asynchronous programming. How is that different from traditional programming? We’re likely used to our code executing like this:

console.log("this will print first");
console.log("this will print second");
console.log("this will print third");

With asynchronous programming, certain event-related functions take callbacks, or functions that are to be executed later, as arguments. This makes it so the execution order is not always so clear:

console.log("this will print first");

$("button").on("click", function () {
    console.log("this will only print when someone clicks");
});

console.log("this will print second");

Here is another example that doesn’t rely on user input for callbacks to be executed. We’ve already seen the ready function, which waits until the DOM is ready to execute the callback. The setTimeout function behaves similarly, but it executes the callback after the specified number of milliseconds have passed:

// This is a jQuery event that executes the callback
// when the DOM is ready. In this example, we're using
// an anonymous function instead of sending the main
// function as an argument
$(document).ready(function () {
    console.log("this will print when the document is ready");
});

// This is a built-in JavaScript function that executes
// after the specified number of milliseconds
setTimeout(function () {
    console.log("this will print after 3 seconds");
}, 3000);

// this will print before anything else, even though
// it appears last
console.log("this will print first");

Right now, event-driven programming based on user interaction probably makes sense, and the examples involving setTimeout and the ready function should be relatively easy to understand. The problems start to arise when we want to sequence events. For example, consider a situation where we are using jQuery’s slideDown function to animate some text sliding down:

var main = function () {
    "use strict";

    // create and hide our content as a div
    var $content = $("<div>Hello World!</div>").hide();

    // append the content to the body element
    $("body").append($content);

    // slide the content down for 2 seconds
    $content.slideDown(2000);
};

$(document).ready(main);

Now suppose we’d like to fade in a second message after the content slides down. We might immediately try to do something like this:

var main = function () {
    "use strict";

    // create and hide our content as a div
    var $content = $("<div>Hello World!</div>").hide();
    var $moreContent = $("<div>Goodbye World!</div>").hide();

    // append the content to the body element
    $("body").append($content);

    // slide the content down for 2 seconds
    $content.slideDown(2000);

    // append the second content to the body
    $("body").append($moreContent);

    // fade in the second content
    $moreContent.fadeIn();
}

$(document).ready(main);

Type in this code and run it. You’ll see that the “Goodbye World!” div fades in while the “Hello World!” div is sliding down. This is not what we wanted. Take a moment and think about why that is happening.

You’ve probably figured out that the slideDown function is happening asynchronously. This means that the code that follows is being executed while the slide down is occurring! Fortunately, jQuery offers us a workaround—most asynchronous functions accept an optional callback parameter as its last argument, which allows us to sequence asynchronous events. So we can achieve the effect we’re shooting for by modifying our code as follows:

var main = function () {
    "use strict";

    // create and hide our content as a div
    var $content = $("<div>Hello World!</div>").hide();
    var $moreContent = $("<div>Goodbye World!</div>").hide();

    // append the content to the body element
    $("body").append($content);

    // slide the content down for 2 seconds
    // and then execute the callback which
    // contains the second content
    $content.slideDown(2000, function () {
        // append the second content to the body
        $("body").append($moreContent);

        // fade in the second content
        $moreContent.fadeIn();
    });
};

$(document).ready(main);

We would use the same approach to finish off our example from the previous section. To remove the p element from the footer when it is finished fading out, we would do something like this:

$("footer p").fadeOut(1000, function () {
    // this will happen when the p element
    // is finished fading out
    $("footer p").remove();
});

Later on in the book, we’ll see other examples of asynchronous programming with Node.js, but for now it’s good to get the hang of these functions and understand the patterns.

It turns out that we don’t have to create an entire project to start playing around with JavaScript. Chrome has a pretty nice interactive JavaScript interpreter built into its Developer Tools!

Let’s start by opening a new window or tab in our browser and open the Chrome Developer Tools as described in the previous chapter (go to View → Developer and click Developer Tools). Next, click the Console tab at the top. You should be greeted with a prompt that looks similar to Figure 4-8.

We can now interact with the JavaScript Console. For example, type in the following code, pressing Enter after each line:

5+2;
//=> 7

Math.random();
//=> 0.3896130360662937

console.log("hello world!");
//=> hello world!

The first line should print out 7, because the numerical expression evaluates to 7. The second line should print out a random decimal number between 0 and 1.

Figure 4-8. The Chrome JavaScript Console

The last line should print out “hello world!” followed by a line that says “undefined.” That’s okay—Chrome always prints out the result of evaluating the last line. The console.log statement does something, but it doesn’t actually evaluate to anything, which is why Chrome prints out undefined.

For the rest of this section, you can type the examples directly into the JavaScript Console with one minor caveat. If you need to type in something that appears on multiple lines (like an if statement or a for loop), you’ll need to press Shift-Enter instead of just Enter at the end of the line. Give it a try by typing in the following code:

var number = 5;

if (number >= 3) {
   console.log("The number is bigger than 3!");
}
//=> The number is bigger than 3!

Also note that you can press the up and down arrows on your keyboard to navigate through your previously typed code snippets (just like you can navigate your command history in your terminal window).

JavaScript is not a strongly typed language. This means that variables can hold any data of any type (like integers, strings, and numbers with decimals). This is different from languages like Java or C++, where variables have to be declared to hold specific types:

// This holds a string
var message = "hello world!";

// These hold numbers
var count = 1;
var pi = 3.1415;

// This holds a boolean
var isFun = true;

console.log(message);
//=> hello world!

console.log(pi);
//=> 3.1415

console.log(isFun);
//=> true

Variable declarations/definitions can be defined as a single statement separated by commas. As I mentioned before, it’s a good idea to put them at the top of your function definition. This convention creates consistency that adds to the readability of your code:

var main = function () {
    "use strict";

    var message = "hello world!",
        count = 1,
        pi = 3.1415,
        isFun = true;

    console.log(message);
};

We’ve seen a lot of examples of functions so far. Unlike C++ and Java, functions are first-class citizens. That means we can assign functions to variables, send in functions as parameters to other functions, and define anonymous functions (which are simply functions without names):

// define a function and store it
// in a variable called sayHello
var sayHello = function () {
    console.log("hello world!");
}

// execute the function in the sayHello variable
sayHello();
//=> "hello world!"

Similar to other languages, JavaScript functions can have inputs and an output. The inputs are often referred to as arguments or parameters and they are specified inside the parentheses of the function definition. The output is often referred to as the return value and is always preceded by the keyword return:

// define a function called add which
// accepts two inputs: num1 and num2
// and has one output: the sum of the
// two numbers
var add = function (num1, num2) {
    // add the inputs, and store the result in sum
    var sum = num1 + num2;

    // return the sum
    return sum;
}

// execute the add function with 5 and 2 as inputs
add(5,2);
//=> 7

One interesting consequence of the fact that functions are first-class objects in JavaScript is that we can use other functions as inputs to functions. We’ve utilized this pattern by sending in anonymous functions as callbacks, but we’ve also used named functions. For example, we sent in a function called main to the ready function in jQuery:

// the main entry point of our program
var main = function () {
    "use strict";
    console.log("hello world!");
};

// set up main to run once the DOM is ready
$(document).ready(main);

Although C++ has function pointers, it doesn’t easily admit anonymous functions so code patterns like those that we’ve seen aren’t often used. Likewise, at least at the time of this writing, Java has no easy mechanism for creating functions that accept other functions as parameters.

In the next chapters, we’ll have the opportunity to write functions that take other functions as parameters. This becomes helpful when we’re doing more complex asynchronous programming.

One of the first control structures we learn in any language is the if statement. This lets us tell the interpreter that a block of code should only be executed if some condition is true:

var count = 101;

if (count > 100) {
   console.log("the count is bigger than 100");
}
//=> the count is bigger than 100

count = 99;

if (count > 100) {
   console.log("the count is bigger than 100");
}
//=> prints nothing

An else statement allows us to do something different if the condition is false:

var count = 99;

if (count > 100) {
   console.log("the count is bigger than 100");
} else {
   console.log("the count is less than 100");
}
//=> the count is less than 100

Sometimes we’ll find that we want to do multiple mutually exclusive things depending on different conditions. When that’s necessary, the if-else-if pattern often comes in handy:

var count = 150;

if (count < 100) {
   console.log("the count is less than 100");
} else if (count <= 200) {
   console.log("the count is between 100 and 200 inclusive");
} else {
   console.log("the count is bigger than 200");
}
//=> the count is between 100 and 200 inclusive

Best of all, conditions don’t have to be simple. We can use the && (and), || (or), and ! (not) operators to build more complex conditions. As mentioned in Chapter 2, the | key is found right above the Enter key on your keyboard—you’ll have to hold down Shift to get it instead of the backslash:

// check to see if *any* of the conditions are true
if (cardRank === "king" || cardRank === "queen" || cardRank === "jack") {
    console.log("that's a high ranking card!");
} else {
    console.log("not quite royalty!");
}

// check if the card is the ace of spades
if (cardRank === "ace" && cardSuit === "spades") {
    console.log("THAT'S THE ACE OF SPADES!");
} else {
    console.log("Sadly, that's not the ace of spades");
}

// check if the card is *not* the ace of spades
// by flipping the output using the ! operator
if (!(cardRank === "ace" && cardSuit === "spades")) {
    console.log("That card is not the ace of spades!");
}

Often, we’ll have to do things multiple times. For example, suppose we want to print out the first 100 numbers. Obviously we can do this in a pretty naive way:

console.log(0);
console.log(1);
console.log(2);
// ... ugh
console.log(99);
console.log(100);

That’s a lot of code! It’s much easier to use a looping structure to print out all 100 numbers:

var num; // this will be the number that we print out

// print 101 numbers starting with 0
for (num = 0; num <= 100; num = num + 1) {
    console.log(num);
}

This achieves the same thing as the preceding code, but in a much more concise way. This is an example of a for loop.

A for loop consists of four (pun intended) things. Three of them are in the parentheses that follow the word for and I refer to those as the initialization statement, the continuation condition, and the update statement. The fourth is the loop body, which is the code that is in between the curly braces. The initialization statement occurs just before the loop body runs for the first time. The update statement runs each time the loop body completes. And the continuation condition is checked right before the loop body is run (even the first time).

Here are two annotated for loops that achieve the same result—printing out the even numbers less than 100:

var i;

// initialization: i gets set to 0
// continuation: keep going as long as i is smaller than 100
// update: add 2 to i
// body: print out i
// in other words, print out only the even numbers starting with 0 and ending
// with 98
for (i = 0; i < 100; i = i + 2) {
    console.log(i);
}

// initialization: i gets set to 0
// continuation: keep going as long as i is smaller than 100
// update: add 1 to i
// body: print out i only if the remainder when dividing i by 2 is 0
// print out only the even numbers starting with 0 and ending with 98
for (i = 0; i < 100; i = i + 1) {
    if (i%2 === 0) {
       console.log(i);
    }
}

In the second example, we use the remainder operator (%), which yields the remainder from integer division. In other words, 5%2 evaluates to 1 because 5/2 is 2 with a remainder of 1. In the example, we’re using this operator to check for divisibility by 2 (which tells us the number is even). Even though this operator may seem esoteric, it’s actually extremely useful. In fact, it’s so useful for experienced programmers that questions involving it are often asked at job interviews for programming positions (see the FizzBuzz practice problem at the end of this chapter).

If you’re familiar with while and do...while loops from Java or C++, you’ll be pleased to know that JavaScript supports these as well. I like keeping it simple, so I’ll only use for loops (and forEach loops on arrays) for the remainder of this book.

Loops are interesting in general, but extraordinarily useful in the context of arrays. Arrays are simply indexed collections of JavaScript entities. One way of thinking of arrays is as a single variable that can hold multiple values. Here’s a simple example that creates an array:

var greetings = ["hello", "namaste", "hola", "salut", "aloha"];

We can generalize this example pretty easily: we create an array literal by using the square brackets and then listing out the elements separated by commas. This array has five elements in it, each of which is a string. Here’s an example with an array of integers:

var primes = [2, 3, 5, 7, 11, 13, 17, 19, 23, 29];

We can index into the arrays to get certain elements by using the variable name followed by square brackets. The indexing for arrays always starts at 0 and ends at one less than the length of the array:

console.log(greetings[1]);
//=> 'namaste'

console.log(greetings[0]);
//=> 'hello'

console.log(primes[4]);
//=> 11

console.log(greetings[4]);
//=> 'aloha'

Likewise, we can set individual elements of the array by using the same indexing trick:

greetings[3] = "bonjour"; // changes 'salut' to 'bonjour'

What if we want to print all the elements of the array? One approach is to use the length property of the array to build a continuation condition for a for loop:

var index;

for (index = 0; index < greetings.length; index = index + 1) {
    console.log(greetings[index]);
}

This is a perfectly valid approach, and one that is often used in JavaScript along with other languages like Java. But JavaScript has a slightly nicer JavaScripty way of achieving the same thing. Every array has a forEach loop attached to it, which takes in a function that operates on each element:

// the forEach loop takes a function as an argument
// and calls it for each element of the array
greetings.forEach(function (element) {
    console.log(element);
});

This is nicer because it removes the need to maintain an extra variable such as index in the previous example. It’s often the case that removing a variable declaration will make our code less error prone.

In addition to including the forEach function, JavaScript arrays have some other advantages over raw arrays in C++ or Java. First, they can grow and shrink dynamically. Second, they have several functions built in that let us do some common operations. For example, we’ll commonly want to add elements to the end of our array. We can use the push function to do that:

// create an empty array
var cardSuits = [];

cardSuits.push("clubs");
console.log(cardSuits);
//=> ["clubs"]

cardSuits.push("diamonds");
console.log(cardSuits);
//=> ["clubs", "diamonds"]

cardSuits.push("hearts");
console.log(cardSuits);
//=> ["clubs", "diamonds", "hearts"]

cardSuits.push("spades");
console.log(cardSuits);
//=> ["clubs", "diamonds", "hearts", "spades"]

There are many other built-in functions on JavaScript arrays, but we’ll leave it with push for now. We’ll learn a few others as we move forward.

Arrays and loops are pretty essential tools no matter what programming language you’re working in. The only way to master them is to practice creating them and using them. Several practice problems at the end of this chapter will get you creating and manipulating arrays using loops.

Because we’ve seen several examples with Git up to this point, I’ll let you decide the appropriate times and places to update your repository in this example. Just make sure that you actually create a Git repository and update it regularly as we work our way through the example.

You’ll also see that I’ve reused much of the design from the last example in the previous chapter. Therefore, you should be able to copy your work (namely, the HTML and the CSS) from the previous chapter. In this case, though, we’ll want to create our javascripts and stylesheets directory to keep our code organized.

We can start by modifying the main element to contain our UI. My HTML for the main element looks like this:

<main>
  <div class="container">
    <div class="tabs">
      <a href=""><span class="active">Newest</span></a>
      <a href=""><span>Oldest</span></a>
      <a href=""><span>Add</span></a>
    </div>
    <div class="content">
      <ul>
        <li>Get Groceries</li>
        <li>Make up some new ToDos</li>
        <li>Prep for Monday's class</li>
        <li>Answer recruiter emails on LinkedIn</li>
        <li>Take Gracie to the park</li>
        <li>Finish writing book</li>
      </ul>
    </div>
  </div>
</main>

You can use this basic structure for the main element, along with your work from Chapter 3 to style the page. Here are the style rules for my tabs:

.tabs a span {
    display: inline-block;
    border-radius: 5px 5px 0 0;
    width: 100px;
    margin-right: 10px;
    text-align: center;
    background: #ddd;
    padding: 5px;
}

You’ll see one new thing here: I’ve set the display property to inline-block. Recall that inline elements like span don’t have a width property, whereas block elements do, but they appear on a new line. The inline-block setting creates a hybrid element, giving the span a width property that I set to 100px. This makes it so every tab has the same width.

Of course, I also have an extra ruleset for the active tab. This makes the active tab have the same color as the content background, which gives the interface some visual depth:

.tabs a span.active {
    background: #eee;
}

Let’s move on to the really interesting part: the JavaScript! Of course, at this point we should have included both jQuery and /javascripts/app.js via a script element at the bottom of our body element in the HTML. So we can start our app.js with our basic skeleton program:

var main = function () {
    "use strict";

    console.log("hello world!");
};

$(document).ready(main);

Recall that if we open this in our browser window, we should see hello world! in the JavaScript Console if everything is set up properly. Go ahead and do that.

var main = function () {
    "use strict";

    $(".tabs a:nth-child(1)").on("click", function () {
        // make all the tabs inactive
        $(".tabs span").removeClass("active");

        // make the first tab active
        $(".tabs a:nth-child(1) span").addClass("active");

        // empty the main content so we can recreate it
        $("main .content").empty();

        // return false so we don't follow the link
        return false;
    });

    $(".tabs a:nth-child(2)").on("click", function () {
        $(".tabs span").removeClass("active");
        $(".tabs a:nth-child(2) span").addClass("active");
        $("main .content").empty();
        return false;
    });

    $(".tabs a:nth-child(3)").on("click", function () {
        $(".tabs span").removeClass("active");
        $(".tabs a:nth-child(2) span").addClass("active");
        $("main .content").empty();
        return false;
    });
};