Learn Enough HTML, CSS and Layout to Be Dangerous

HyperText Markup Language

Part I of Learn Enough HTML, CSS and Layout to Be Dangerous, also known as Learn Enough HTML to Be Dangerous (https://www.learnenough.com/html), is an introduction to HyperTextMarkup Language, the language of the World Wide Web. It doesn’t assume any prior knowledge of web technologies (though readers of Learn Enough Developer Tools to Be Dangerous will quickly realize they got a big head start when developing a sample website using version control).

Like all Learn Enough tutorials, Learn Enough HTML to Be Dangerous is structured as a technical narrative, with each step carefully motivated by real-world uses. Chapter 1 starts with a “hello, world!” page that you’ll immediately deploy to production (!). We’ll then fill in the index page with formatted text, links, and images in Chapter 2, expanding it into a multiple-page site with more advanced features like tables and lists in Chapter 3. Finally, we’ll add some inline styling in Chapter 4, which will allow us to see the effect of simple style rules on plain HTML elements.

The result of finishing Learn Enough HTML to Be Dangerous is a mastery of the core HTML needed for making static websites. It also gives you a big head start on learning how to develop dynamic web applications with technologies like JavaScript (Learn Enough JavaScript to Be Dangerous (https://www.learnenough.com/javascript)) or Ruby and Ruby on Rails (Learn Enough Ruby to Be Dangerous (https://www.learnenough.com/ruby) and the Ruby on Rails Tutorial (https://www.railstutorial.org/)).

Cascading Style Sheets and Page Layout

Building on the simple styling techniques introduced in Chapter 4 of Part I, Part II— also known as Learn Enough CSS and Layout to Be Dangerous (https://www.learnenough.com/css-and-layout)—covers both web design with Cascading Style Sheets and front-end web development with a static site generator. We know of no comparable tutorial that brings all this material together in one place, and the result is the ability to make and deploy websites that are attractive, maintainable, and 100% professional-grade.

In Chapter 5, we’ll learn the basics of CSS declarations and values by starting with a few super-simple elements on a sample page. We’ll end with a first introduction to the essential technique of CSS selectors to target particular page elements for styling. In Chapter 6, we’ll discuss aspects of selectors that are important to get right at the beginning of a project, with a focus on managing complexity and maintaining flexibility by choosing good names for things (including an introduction to CSS color conventions).

Chapter 7 introduces two of the most important kinds of CSS values: colors and sizes. These lay an essential foundation for Chapter 8 on the box model, which determines how different elements fit together on the page.

In Chapter 9 and Chapter 10, we’ll take the page that we’ve been working on and factor it into a layout using a static site generator called Jekyll to build professional-grade websites that are easy to maintain and update. In Chapter 11, we’ll learn how to make flexible page layouts using flexbox, adding layouts for a photo gallery page (covered in Learn Enough JavaScript to Be Dangerous) and a blog with posts.

In Chapter 12, we’ll add the blog itself, showing how to use Jekyll to make a professional-grade blog without black-box solutions like WordPress or Tumblr. Because a large and growing amount of web traffic comes from mobile devices, in Chapter 13 we’ll cover the basics of using CSS and media queries to make mobile-friendly sites without violating the DRY (“Don’t Repeat Yourself ”) principle.

As a concluding step in developing the main sample application, in Chapter 14 we’ll add the kinds of little details that make a site feel complete. The result will be an industrial-strength, nicely styled site deployed to the live Web.

Finally, as a special bonus, in Chapter 15 we’ll introduce a more recent and advanced layout technique known as CSS grid. The result is a largely self-contained discussion of how to use grid to accomplish some of the same effects mentioned in previous chapters, as well as some effects you can only accomplish easily with grid.

Custom Domains

In Part III, also known as Learn Enough Custom Domains to Be Dangerous (https://www.learnenough.com/custom-domains), you’ll learn how to associate your website with a custom domain. This means your site will live at a domain like example.com instead of example.someoneelsesdomain.com—in other words, at a domain you control and that no one can ever take away.

Chapter 16 shows you how to register a custom domain, including guidance on how to pick a good domain name and a discussion of the pros and cons of various top-level domains (TLDs). You’ll also learn how to use Cloudflare to configure the DNS settings for your custom domain. As part of this, you’ll learn how to use Secure Sockets Layer/Transport Layer Security (SSL/TLS) to make sure your site is secure and how to redirect URLs for a more pleasant user experience.

Chapter 17 shows you how to use custom email addresses with your domain using Google Workspace. The result is the ability to use yourname@example.com instead of yourname152@gmail.com. As a special bonus, you’ll learn how to use another Google service, Google Analytics, to monitor traffic to your site and gain insight into how visitors are using it.

Additional Features

In addition to the main tutorial material, Learn Enough HTML, CSS and Layout to Be Dangerous includes a large number of exercises to help you test your understanding and to extend the material in the main text. The exercises include frequent hints and often include the expected answers, with community solutions available by separate subscription at www.learnenough.com.

Final Thoughts

Learn Enough HTML, CSS and Layout to Be Dangerous covers everything you need to know to make a website for a personal homepage, hobby, or business—it’s basically a one-stop shop for all things “Web.” After learning the techniques covered in this tutorial, and especially after developing your technical sophistication, you’ll know everything you need to design and deploy professional-grade websites. You’ll also be ready for a huge variety of other resources, including books, blog posts, and online documentation. Learn Enough JavaScript to Be Dangerous, which builds on this tutorial to make a website with an interactive image gallery, is especially recommended. You can even go on to learn dynamic, database-backed web development with Learn Enough Ruby to Be Dangerous and the Ruby on Rails Tutorial.

Learn Enough Scholarships

Learn Enough is committed to making a technical education available to as wide a variety of people as possible. As part of this commitment, in 2016 we created the Learn Enough Scholarship program (https://www.learnenough.com/scholarship). Scholarship recipients get free or deeply discounted access to the Learn Enough All Access subscription, which includes all of the Learn Enough online book content, embedded videos, exercises, and community exercise answers.

As noted in a 2019 RailsConf Lightning Talk (https://www.learnenough.com/scholarship-talk), the Learn Enough Scholarship application process is incredibly simple: just fill out a confidential text area telling us a little about your situation. The scholarship criteria are generous and flexible—we understand that there are an enormous number of reasons for wanting a scholarship, from being a student, to being between jobs, to living in a country with an unfavorable exchange rate against the U.S. dollar. Chances are that, if you feel like you’ve got a good reason, we’ll think so, too.

So far, Learn Enough has awarded more than 2,500 scholarships to aspiring developers around the country and around the world. To apply, visit the Learn Enough Scholarship page at www.learnenough.com/scholarship. Maybe the next scholarship recipient could be you!

1.1 Introduction

Underneath every website, no matter how simple or complex, you will find HTML. In Part I, by creating and deploying a simple but real website, we’ll gain an understanding of the underlying structure that every site uses to organize and display content online.

As a technology standard, HTML has been constantly evolving ever since its introduction in 1993 by Tim Berners-Lee, the original “web developer” (Figure 1.2).⁴

4. Image courtesy of dpa picture alliance/Alamy Stock Photo.

Nowadays, the specification of what’s in HTML and what isn’t is managed by the World Wide Web Consortium (W3C). The latest public release, which is what we will be using in this tutorial, is HTML5 (that is, version 5 of HTML). The companies that create web browsers take the specs from the W3C and implement the behaviors that are expected when the browser comes across any of the allowed formatting, such as making text bold or changing its color (or even doing both at the same time).

Fortunately, we won’t need to get into a lot of specifics or worry about what has changed from version to version. Just know that new features are being added regularly to expand browser functionality and modernize the technology. Common elements, including the ones we’ll be covering in this tutorial, haven’t changed much since the beginning, but that doesn’t mean that they will always be safe—the HTML spec is a constantly evolving creature being assembled by a committee (Figure 1.3).⁵ We’ll discuss some practical effects of this in Section 1.2.

5. Image courtesy of Aleksandr Frolov/123RF.

1.2 HTML Tags

As the name HyperText Markup Language indicates, HTML is a markup language, which allows a web author to organize and define how content should be displayed. This means HTML can do things like add text formatting; make headings, lists, and tables; and include images and links. You can think of an HTML file as an ordinary written document that has been carefully annotated by the author with instructions on how to display it. Some of these annotations might highlight parts of the text, some might include an image that has been added to the document, and others might tell you where to find additional information.

The “HyperText” part of the HTML initialism refers to the way links on the Web allow you to move from one document to another in a non-linear fashion. For example, if you are reading the Wikipedia article on HTML and see a highlighted link to a related topic like CSS, you can click on that link and be taken immediately to the other article. It also allows a document like this one to link to Wikipedia. (You might notice that external links in this document open in a new browser tab. We’ll learn how to do this ourselves in Section 3.3.)

Technologically, hypertext is a great improvement over non-linked documents, as it eliminates the need to flip or scroll through pages of content to find what you are looking for. These days, the ability to link between documents is something that we all take for granted, but when the HTML specification was created it was an innovation important enough to be included in the name of the technology.

HTML source is plain text, which makes it ideal for editing with a text editor (as discussed in Learn Enough Text Editor to Be Dangerous). Instead of using the convenient but inflexible What You See Is What You Get (WYSIWYG) approach of word processors, HTML indicates formatting using special tags which are the text annotations alluded to above.

As we’ll see, HTML supports more than one kind of tags, but the most common kind consist of strings (sequences of characters) enclosed in beginning and ending tags, like this:

Click here to view code image

<strong>make them strong</strong>

Figure 1.4 illustrates the detailed anatomy of this typical tag, including the name of the tag (strong, in this case), angle brackets, and a forward slash (/).

Although HTML tags are not visible to the end-user (i.e., the person viewing your website), they do give the web browser suggestions about how to format the content and how it should be displayed on the page. A simple example using the strong tag appears in Listing 1.1.

Listing 1.1: A string with HTML tags in the text.

Click here to view code image

I am a string about things. Some of those things are more important than others, so I
will <strong>make them strong</strong> to stand out among less spectacular neighbors.

Most browsers render the strong tag as boldface text, so in a typical browser Listing 1.1 would appear something like this:

I am a string about things. Some of those things are more important than others, so I will make them strong to stand out among less spectacular neighbors.

If we were to split the contents of the strong tag in Listing 1.1 onto two lines by hitting return after “them”, the browser would ignore the extra space and format the string as a continuous line of text.

By the way, HTML does support a b (bold) tag in addition to strong, but over the years HTML has moved away from tag names that specify formatting (i.e., “make the text bold”) and toward names that focus on meaning—or, in fancier terms, semantics—leading to an emphasis on so-called semantic tags (Box 1.2). For example, the semantic tag strong indicates that the enclosed text should be made to look “strong” somehow, letting the browser decide exactly how to do it.

At this point, we’ve covered the conceptual core of HTML: HTML consists of text content wrapped in tags, which organize or indicate a change in the display of that content.

But the Devil, as they say, is in the details… and HTML has a whole lot of details.

<p>
  William Shakespeare's <em>Sonnets</em> consists of 154 poems, each fourteen
  lines long (three
  <a href="https://en.wikipedia.org/wiki/Quatrain">quatrains</a>
  followed by a rhyming
  <a href="https://en.wikipedia.org/wiki/Couplet">couplet</a>).
  <strong>Sonnet 18</strong> is perhaps the most famous, and begins like this:
</p>
<blockquote>
  <p>
    Shall I compare thee to a summer's day?<br>
    Thou art more lovely and more temperate.
  </p>
</blockquote>

1.3 Starting the Project

Now that we know the basic structure of markup and tags, it’s time to get started with the project that will serve as our sample website for learning HTML. The sample project is a mock informational website, whose main page talks a little about this tutorial, the company behind it, and HTML itself. As we develop the homepage and two ancillary pages, we’ll see how to use a wide variety of HTML tags, while also showing you how to make the kind of public-facing site that you could use for your own work or as a service to other people. Although some of the information on the site is about Learn Enough to Be Dangerous, ultimately it is about you.

We’ll begin by following the same steps used in Learn Enough Git to Be Dangerous, so this section will also serve as a review of how to use Git. (If you don’t have Git proficiency at the level of Learn Enough Git to Be Dangerous, we recommend you read that tutorial at this time.) As in the Git tutorial, the result here will be that we can deploy our sample HTML site to the live Web using GitHub Pages (Box 1.3).

We’ll get started by making a directory and an initial repository for our sample website. First, open a terminal window⁶ and make a directory called sample_website⁷:

6. Note for Mac users: Although it shouldn’t matter in Learn Enough HTML to Be Dangerous, it is recommended that you use the Bourne-again shell (Bash) to complete this tutorial. To switch your shell to Bash, run chsh -s /bin/bash at the command line, enter your password, and restart your terminal program. Any resulting alert messages are safe to ignore. See the Learn Enough blog post “Using Z Shell on Macs with the Learn Enough Tutorials” (https://news.learnenough.com/macos-bash-zshell) for more information.

7. The command mkdir -p is covered in Section 8.2 of Learn Enough Developer Tools to Be Dangerous. Unless otherwise indicated, every command we use in Learn Enough HTML to Be Dangerous is covered somewhere in Learn Enough Developer Tools to Be Dangerous, so we recommend you look there if you run across any commands that don’t look familiar.

Click here to view code image

$ mkdir -p repos/sample_website

Next, cd into the directory and touch the file for the main page of the site, which should be called index.html:

Click here to view code image

$ cd repos/sample_website
$ touch index.html

Then initialize the repository:

Click here to view code image

$ git init
$ git add -A
$ git commit -m "Initialize repository"

The reason we created a file using touch is because Git won’t let you make a commit in an empty repository.⁸ The reason we’ve called it index.html is because that’s the default filename for “home” pages on the Web, and most sites will automatically serve up index.html when you hit the bare domain. In other words, when you point a browser at example.com, the server will automatically show you exam-ple.com/index.html. (Those links work, by the way; amazingly, the HTML standard specifically reserves the site example.com for examples just like this one!)

8. As mentioned in Chapter 2 of Learn Enough Developer Tools to Be Dangerous, the touch technique is a personal favorite, but the file doesn’t have to be empty; for example, echo hello > index.html would also have worked.

With the repo initialized, we’re now ready to push our (nearly) empty repo up to GitHub. As in Learn Enough Git to Be Dangerous, you should go to github.com (https://github.com/), log in if necessary, and then create a new repository using the name sample_website and the description “A sample website for Learn Enough HTML to Be Dangerous”, as shown in Figure 1.5.⁹

9. GitHub is constantly updating its user interface (UI), so in these and other figures you may notice slight differences compared to what you see in your browser. Use your technical sophistication (Box 5.1) to resolve any discrepancies.

After creating the remote repo, you should set the remote origin as the URL for the repo, which you can find as shown in Figure 1.6 (or just copy from the section “…or push an existing repository from the command line” on the GitHub setup page). This involves using git remote to set the origin URL and then pushing the main branch “upstream” using git push -u:¹⁰

10. The screencasts that are available to accompany this book refer to the master branch, which was the default branch name for the first 15+ years of Git’s existence, but the text has been updated to use main, which is the current preferred default. See the Learn Enough blog post “Default Git Branch Name with Learn Enough and the Rails Tutorial” (https://news.learnenough.com/default-git-branch-name-with-learn-enough-and-the-rails-tutorial) for more information.

Click here to view code image

$ git remote add origin <repo url>
$ git push -u origin main

At this point, you will be prompted for your password, which (as noted in Learn Enough Git to Be Dangerous) must be a personal access token rather than your GitHub password. See the GitHub article “Creating a personal access token” (https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) for more information.¹¹

11. As of this writing, the article is at https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token, but Googling “github creating personal access token” is also a good bet.

At this point, you should click on the Settings tab for your new repository and follow the instructions for serving your website from the main branch using GitHub Pages, as discussed in Section 11.4 of Learn Enough Developer Tools to Be Dangerous and reviewed in Figure 1.7.

As soon as you click the Save button, the sample website will be live on the Web via GitHub Pages! Its location is given by a github.io URL based on the username and repo name (Listing 1.3).

Listing 1.3: The template for a GitHub Pages URL.

Click here to view code image

https://<username>.github.io/<repo_name>

For example, the Learn Enough version of the sample website lives at the URL

https://learnenough.github.io/sample_website_reference_implementation

Incidentally, that means it can be cloned from here for future reference:¹²

12. Keeping the reference website in sync with the main tutorial is a challenging task, so reports of any discrepancies are gratefully received. You can send such reports to support@learnenough.com.

https://github.com/learnenough/sample_website_reference_implementation

If you visit your version of this site, it should resolve properly, and it should even automatically serve up the contents of index.html. Because those contents are empty, though, all you’ll see is a blank white screen. We’ll take our first steps toward changing this sad state of affairs in Section 1.4, and then we’ll knock it up a notch starting in Chapter 2.

1.4 The First Tag

In order to initialize the Git repository in Section 1.3, we needed only an empty index.html file, but of course our sample site will eventually have much more than that. In this section, we’ll begin by adding some content in a single tag—just enough to give us a site to view, commit, and deploy. That’s a huge accomplishment, though, and will serve as an essential foundation for what follows.

Now that an empty index page has been created, you should open index.html using your favorite editor, which for the purposes of this tutorial we’ll assume is Atom. It’s possible to open the file directly using File > Open, but (as noted in Section 7.4 of Learn Enough Developer Tools to Be Dangerous) these days all the cool kids open the full HTML project directly at the command line:

$ atom .

(As noted in Section 4.3 of Learn Enough Developer Tools to Be Dangerous, the . (“dot”) refers to the current directory.)

Even though we have only one file for now (and possibly a README (Section 1.3.1)), opening the full project is a good habit to cultivate, since it allows us to easily open and edit multiple files in the same project. We’ll put this technique to good use when we start making additional pages in Section 3.1.

At this point, we’re ready to fill the index file with some content, which should consist of the phrase “Hello, world!” (Listing 1.4) enclosed in the paragraph tag p. Note that the p tag has exactly the same form as the strong tag (Figure 1.4).

Listing 1.4: A short paragraph with the contents “Hello, world!”.
index.html

<p>Hello, world!</p>

We see in Figure 1.8 that Atom automatically highlights the HTML source, which it knows to do because of the .html extension on the filename. This syntax highlighting is irrelevant to the computer—in fact, it takes place purely in the editor and doesn’t have anything to do with index.html itself—but it makes it easier for humans to distinguish the difference between tags and content. (This is also why we use syntax highlighting in this tutorial’s code listings.)

Having made a change to add content to index.html, let’s view the result in a browser. On macOS, you can do this using the open command:

Click here to view code image

$ open index.html   # macOS only

On many Linux systems, you can use the similar xdg-open command:

Click here to view code image

$ xdg-open index.html   # Linux only

A technique that works on almost any system is to view the sample_website directory in a graphical file browser and double-click the filename. No matter how you do it, the result should be to open index.html in the default browser on your system, which should appear something like Figure 1.9.

Note that the “URL” in Figure 1.9 will be a local file, like this:

Click here to view code image

file:///Users/mhartl/repos/sample_website/index.html

This is because the index page is on our local system and hasn’t yet been deployed to the live Web.

We know how to remedy this, though—commit our changes to the local Git repository and push up to GitHub Pages:

Click here to view code image

$ git commit -am "Add a short paragraph"
$ git push

Upon refreshing the browser pointed at the sample website’s GitHub Pages URL (Listing 1.3), we will see “Hello, world!”. (You may have to wait a few moments for GitHub Pages to load your site. This happens only the first time, and on subsequent requests the response will be lightning-fast.)

Although the appearance is identical to the local version in Figure 1.9, by inspecting the address bar you should be able to confirm that the URL is at github.io, which means that the page is now available on the live Web.

Congratulations! You’ve just published a production website.

1.5 An HTML Skeleton

Although modern web browsers are highly fault-tolerant and will render simple HTML like Listing 1.4 just fine, it’s dangerous to rely on this behavior. Indeed, we saw in Learn Enough Git to Be Dangerous that omitting a single tag resulted in the trademark character^™ not rendering properly (Figure 1.10). This is exactly the sort of thing that can go wrong when you don’t use a fully valid HTML page. To avoid these sorts of problems, from now on all of our sample web pages will use valid HTML to ensure that they will render properly in the broadest possible range of browsers.

The prototypical HTML skeleton begins with an html tag containing two elements, a head and a body. These latter tags are nested inside the html tag, as follows:

Click here to view code image

<html><head></head><body></body></html>

Because this is hard to read, it’s conventional to format the tags using spaces and newlines to make the structure more apparent at a glance:

<html>
  <head>
  </head>
  <body>
  </body>
</html>

Because HTML generally ignores extra space, it makes no difference in the appearance of the page, but this formatting makes it easier for us to understand the source of the document (Box 1.4).

The section of the HTML that is wrapped by <head> and </head> is a header container that defines metadata, a fancy word that just means data about data. This <head> section is not displayed to users in their browser window, and therefore gives developers the ability to tell the browser where to find other files (such as CSS and JavaScript) that will be used to properly display the page’s content, without having that information show up in the actual content of the web page. (We’ll cover more things that can be added to the HTML header starting in Part II.)

Meanwhile, the content inside <body> and </body> is what gets displayed to the browser. Every website you’ve ever seen consists of content inside an HTML body tag. Once we’ve defined the contents of the head tag, most of the modifications we’ll make to the site will be inside the body tag.

To complete the skeleton, there are only two more elements: one required and one optional but strongly recommended. First, we need to tell browsers what the document type is, and inside the head tag we need to define a nonempty title, as seen in Listing 1.5.

Listing 1.5: A nearly complete HTML skeleton.

<!DOCTYPE html>
<html>
    <title>Page Title</title>
  </head>
  <body>
  </body>
</html>

Here the DOCTYPE is an irregular tag, and you should not spend even a millisecond worrying about its exact form. (Why is there an exclamation point before DOCTYPE? We have no idea.) Meanwhile, the title tag has exactly the same form as the p tag we saw in Section 1.4 (and the strong tag before that (Figure 1.4)).

As you can verify by using the W3C HTML validator (https://validator.w3.org/), the page in Listing 1.5 validates as HTML5 (Figure 1.11). (An empty title would be invalid, but an empty body is fine. Also note that, although there are no errors on the page, there is a warning regarding the absence of a lang (language) attribute; we’ll address this detail in Section 3.3.1.)

On the other hand, we learned in Learn Enough Git to Be Dangerous (Figure 1.10) that we need one more thing: We need to tell the browser which character set to use so that it can handle the expanded range of characters (called Unicode), which includes symbols like ™ and ©, accented characters (as in voilà), etc. We can do this by adding the meta tag to the head, as shown in Listing 1.6.

Listing 1.6: Adding a meta tag to define the character set.

<!DOCTYPE html>
<html>
  <head>
    <title>Page Title</title>
    <meta charset="utf-8">
  </head>
  <body>
  </body>
</html>

By the way, the meta tag is a special kind of tag called a void element, and doesn’t have a closing tag. Because of this, void elements are also called self-closing tags.

With that, the skeleton is complete!

Because of the importance of this HTML skeleton, let’s review its elements line by line:

1. The doctype declaration

2. Opening html tag

3. Opening head tag

4. Opening and closing title tags (with the content of the page title)

5. The meta tag defining the character set

6. Closing head tag

7. Opening body tag

8. Closing body tag

9. Closing html tag

Combining the original paragraph from Listing 1.4 with the skeleton in Listing 1.6 gives us the code for the first valid HTML page in our sample website, as shown in Listing 1.7.

Listing 1.7: A valid “Hello, world!” page.
index.html

<!DOCTYPE html>
<html>
  <head>
    <title>Page Title</title>
    <meta charset="utf-8">
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

Note in Listing 1.7 that we’ve placed the paragraph from Listing 1.4 inside the body tag, as required by the HTML standard.

After refreshing the browser, the result of Listing 1.7 is virtually the same as we saw in Figure 1.9. The only visible difference in the body of the page is a small amount of additional space around the paragraph.

A second, browser-dependent difference involves the page title, which some browsers display in the default tab, and others don’t show unless you have a second tab in addition to the first (Figure 1.12). In any case, the page title is needed even if it’s not displayed, as it’s required by the HTML standard, and is important for screen readers and the web spiders used by search engines to index the Web.

With that, we’re ready to commit our changes and push the results to GitHub Pages:

Click here to view code image

$ git commit -am "Convert index page to fully valid HTML"
$ git push

The result appears in Figure 1.13.

<!DOCTYPE html>
<html>
  <head>
    <title>Page Title
    <meta charset="utf-8">
  </head>
  <body>
  </body>
</html>

<!DOCTYPE html>
<html>
  <head>
    <title>Who am I?</title>
    <meta charset="utf-8">
  </head>
  <body>
    Jean Valjean
    55 Rue Plumet
    Amonate, VA 24601
  </body>
</html>

2.1 Headings

As noted in Section 1.3, our main index page will include some information about Learn Enough to Be Dangerous, so we’ll start by updating the title tag contents with a new title. Then, we’ll replace the paragraph in the HTML body with several headings, constituting an outline of our document. The results appear in Listing 2.1.

Listing 2.1: Scoping out our index page with headings.
index.html

Click here to view code image

<!DOCTYPE html>
<html>
  <head>
    <title>Learn Enough to Be Dangerous</title>
    <meta charset="utf-8">
  </head>
  <body>

    <h1>The Learn Enough Story</h1>

    <h2>Background</h2>

    <h2>Founders</h2>

    <h3>Michael Hartl</h3>

    <h3>Lee Donahoe</h3>

    <h3>Nick Merwin</h3>

  </body>
</html>

Listing 2.1 shows how to use the HTML header tags h1, h2, and h3, which represent three levels of headings. In this case, the top-level h1 heading contains the main subject of the page:

Click here to view code image

<h1>The Learn Enough Story</h1>

The next two headings indicate additional subjects—in this case, some background on the company and some details about the founders:

<h2>Background</h2>

<h2>Founders</h2>

Because these subjects are subsidiary to the main story, they use the second-level heading h2. Finally, Listing 2.1 uses the third-level heading h3 to list the three Learn Enough founders:

<h3>Michael Hartl</h3>

<h3>Lee Donahoe</h3>

<h3>Nick Merwin</h3>

As you might guess, most browsers render the top-level h1 heading in a large font size, with h2 and h3 getting progressively smaller. (Figuring out how many heading sizes HTML supports is left as an exercise (Section 2.1.1).) The result appears in Figure 2.1.

2.2 Text Formatting

Having added the headings to block out the structure of our document, let’s now add an introductory paragraph describing the subject of the page. Unlike our previous one-line paragraph (Listing 1.4), this paragraph will include several lines, as well as requiring some text formatting (this section) and a link (Section 2.3).

The paragraph itself appears in Listing 2.2, where the vertical dots indicate omitted content (just so we don’t have to include all the tags in every code listing).

Listing 2.2: Adding a paragraph.
index.html

Click here to view code image

  <h1>The Learn Enough Story</h1>

  <p>
     Learn Enough to Be Dangerous is a leader in the movement to teach
     technical sophistication, the seemingly magical ability to take
     command of your computer and get it to do your bidding. This includes
     everything from command lines and coding to guessing keyboard shortcuts,

     Googling error messages, and knowing when to just reboot the darn thing.
     We believe there are at least a billion people who can benefit from
     learning technical sophistication, probably more. To join our
     movement, sign up for our official email list now.
  </p>
  .
  .
  .

Note that the content is now indented inside the p tag. As discussed in Box 1.4, this makes the structure easier to see without affecting the appearance of the page.

It’s also worth noting that Listing 2.2 includes newlines at the end of each line, but this is mainly so that the paragraph contents fit within the constraints of a book. As seen in Figure 2.2, these newlines don’t have any effect on the display, and in real life it’s probably more common to have the content be all on one line, and simply enable word wrap (called “soft wrap” in Atom), as described in Section 6.2 of Learn Enough Developer Tools to Be Dangerous. This is what we recommend you do if you type the contents of Listing 2.2 in by hand.

2.2.1 Emphasized Text

The paragraph in Listing 2.2 has the right content, but it also introduces the new term technical sophistication, and it’s a common typesetting convention to emphasize such terms using italics. As mentioned briefly in Box 1.2, we can accomplish this using the em tag, like this:

Click here to view code image

<em>technical sophistication</em>

Applying this idea to Listing 2.2 gives the result shown in Listing 2.3.

Listing 2.3: Emphasized text.
index.html

Click here to view code image

  <h1>The Learn Enough Story</h1>

  <p>
    Learn Enough to Be Dangerous is a leader in the movement to teach
    <em>technical sophistication</em>, the seemingly magical ability to take
    command of your computer and get it to do your bidding. This includes
    everything from command lines and coding to guessing keyboard shortcuts,
    Googling error messages, and knowing when to just reboot the darn thing.
    We believe there are at least a billion people who can benefit from
    learning technical sophistication, probably more. To join our
    movement, sign up for our official email list now.
  </p>

We can confirm that this worked by refreshing the browser, which shows that technical sophistication is properly emphasized (Figure 2.3).

2.2.2 Strong Text

As we saw briefly in Section 1.2, another possibility for drawing attention to particular text is to make it strong using the strong tag, which most browsers render as boldface text. In this case, we’d like to indicate the strength of our belief that at least a billion people can potentially benefit from learning technical sophistication, which we can do like this:

Click here to view code image

<strong>at least a billion people</strong>

Applying this idea to Listing 2.3 gives Listing 2.4.

Listing 2.4: Strong text.
index.html

Click here to view code image

  <p>
    Learn Enough to Be Dangerous is a leader in the movement to teach
    <em>technical sophistication</em>, the seemingly magical ability to take
    command of your computer and get it to do your bidding. This includes
    everything from command lines and coding to guessing keyboard shortcuts,
    Googling error messages, and knowing when to just reboot the darn thing.
    We believe there are <strong>at least a billion people</strong> who
    can benefit from learning technical sophistication, probably more. To
    join our movement, sign up for our official email list now.
  </p>

Refreshing the browser confirms that the text is now set in bold (Figure 2.4).

  <h2>Founders</h2>

  <p>
    Learn Enough to Be Dangerous was founded in 2015 by Michael Hartl, Lee
    Donahoe, and Nick Merwin. We believe that the kind of technical
    sophistication taught by the Learn Enough tutorials can benefit
    at least a billion people, and probably more.
  </p>

2.3 Links

As mentioned in Section 1.2, much of the point of the Web is hypertext, with hyperlinks that let us move from one page to the next. The way to make such hyperlinks (or links for short) is with the HTML anchor tag a. (Why isn’t it called link? We don’t know, but at least a is short.)

In reading the paragraph from Listing 2.2, you may have noticed that the line

Click here to view code image

sign up for our official email list now

is practically begging for a link to a place where people can actually sign up for the email list. The exact text to use for the link is the subject of some debate, with some holding that links should be nouns and others preferring to link a call to action if possible. We take a pragmatic approach, linking based on what seems most natural. In this case, we’ll go with linking the text “sign up for our official email list”, like this:

Click here to view code image

<a href="https://learnenough.com/email">sign up for our official email list</a>

This contains our first example of an attribute, which is a bit of text inside an HTML tag that supplies extra information about how to process it. In this case, the attribute is href, for “hypertext reference”, and the value is the URL for the Learn Enough email list sign-up form.

Adding the email list link to the paragraph from Listing 2.4 gives Listing 2.6. Note how the text of the link breaks across two lines (something we saw before in Listing 1.1). Because HTML is insensitive to whitespace, this is effectively the same as having it all on one line.

Listing 2.6: Adding a link.

Click here to view code image

  <p>
    Learn Enough to Be Dangerous is a leader in the movement to teach <em>
    technical sophistication</em>, the seemingly magical ability to take
    command of your computer and get it to do your bidding. This includes
    everything from command lines and coding to guessing keyboard shortcuts,
    Googling error messages, and knowing when to just reboot the darn thing.
    We believe there are <strong>at least a billion people</strong> who
    can benefit from learning technical sophistication, probably more. To
    join our movement, <a href="https://learnenough.com/email">sign
    up for our official email list</a> now.
  </p>

The result of Listing 2.6 appears in Figure 2.5.

Now that we know how to make links, we’re ready to add a paragraph on the background of Learn Enough to Be Dangerous, which is rich with links and includes further examples of the text-formatting tags shown in Section 2.2. The resulting paragraph, shown in Listing 2.7, should be placed under the second-level heading from Listing 2.1. Because it contains so many good examples of the tags we’ve covered so far, we recommend you type it in by hand.

Listing 2.7: Adding a paragraph using several useful tags.

Click here to view code image

  <h2>Background</h2>

  <p>
    Learn Enough to Be Dangerous is an outgrowth of the
    <a href="https://railstutorial.org/">Ruby on Rails Tutorial</a> and the
    <a href="https://www.softcover.io/">Softcover publishing platform</a>.
    This page is part of the sample site for
    <a href="https://www.learnenough.com/html"><em>Learn Enough HTML to
    Be Dangerous</em></a>, which teaches the basics of
    <strong>H</strong>yper<strong>T</strong>ext <strong>M</strong>arkup
    <strong>L</strong>anguage, the universal language of the World Wide Web.
    Other related tutorials can be found at
    <a href="https://www.learnenough.com/">learnenough.com</a>.
  </p>

It’s worth noting that Listing 2.7 contains an example of tag nesting, in the form of the link to the present tutorial:

Click here to view code image

<a href="..."><em>Learn Enough HTML to Be Dangerous</em></a>

As you might expect, this produces a link to emphasized text, as shown in Figure 2.6. You might also note that some of the links in Figure 2.6 are a different color, which is an indication that the links have been followed. (This is the default behavior for link colors, but it can be overridden by CSS, as discussed in Learn Enough CSS & Layout to Be Dangerous (https://www.learnenough.com/css-and-layout) and mentioned briefly in Section 4.6.1.)

   <h3>Michael Hartl</h3>

   <p>
     Michael is the creator of the <a href="https://www.railstutorial.org/">
     Ruby on Rails Tutorial</a> and principal author of the
     <a href="https://www.learnenough.com/">Learn Enough to Be Dangerous</a>
     introductory sequence. He is an advanced student of
     <a href="https://www.kravmaga.com/">Krav Maga</a> and has a three-step
     plan for world domination. Rumors that he's secretly a supervillain
     are slightly exaggerated.
   </p>

   <h3>Lee Donahoe</h3>

   <p>
     When he's not literally swimming with sharks or hunting powder stashes
     on his snowboard, you can find Lee in front of his computer designing
     interfaces, doing front-end development, or writing some of the
     interface-related Learn Enough tutorials.
   </p>

   <h3>Nick Merwin</h3>

   <p>
     You may have seen him shredding guitar live with Capital Cities on Jimmy
     Kimmel, Conan, or The Ellen Show, but rest assured Nick is a true nerd
     at heart. He's just as happy shredding well-spec'd lines of code from a
     tour bus as he is from his kitchen table.
   </p>

   <h3>Michael Hartl</h3>
   .
   .
   .
   <p>
     You should follow Michael on Twitter
     <a href="https://twitter.com/mhartl">here</a>.
   </p>

   <h3>Lee Donahoe</h3>
   .
   .
   .
   <p>
     You should follow Lee on Twitter
     <a href="https://twitter.com/leedonahoe">here</a>.
   </p>

   <h3>Nick Merwin</h3>
   .
   .
   .
   <p>
     You should follow Nick on Twitter
     <a href="https://twitter.com/nickmerwin">here</a>.
   </p>

2.4 Adding Images

At this point, our index page is coming into shape, but it’s still missing a critical feature: What would a website be without images (of cats!)? Fortunately, adding images is similar to adding links, although there is an important difference in the structure of the tags. Recall from Section 2.3 that anchor tags take the form

Click here to view code image

<a href="https://example.com/">Example site</a>

We can include images in a similar way using the img tag, with a source attribute src and an alternate attribute alt:

Click here to view code image

<img src="images/kitten.jpg" alt="An adorable kitten">

Here src has a path to the image (either on the filesystem or on the Web), while alt lets developers add a bit of alternate text that describes the image in words. On some browsers, this text will display if the user’s browser has a problem loading the image, but more importantly, it will be read aloud (or even presented as braille) by screen readers used by the visually impaired and is required by the HTML standard.¹

1. The alt attribute is also useful to tell the search engine “spider” programs that crawl the Web which things appear in the image.

The important difference mentioned above is that the img tag doesn’t look like a typical tag, with content inside open and closing tags (Figure 1.4). If it did, it would look like this:

Click here to view code image

<img src="…" alt="…">content</img>

Instead, the img tag has no content and no closing tag:

<img src="…" alt="…">

That final > is all that’s needed to close an img tag—like the meta tag discussed in Section 1.5, img is a void element (self-closing tag). A second variant uses /> at the end, like this:

<img src="…" alt="…" />

This syntax is designed to conform to XML, a markup language related to HTML, but using /> is not required in HTML5. We mention it mainly because you will still sometimes run across the XML-style syntax in other people’s markup, and it’s important to know that the two styles are exactly equivalent.

Because the World Wide Web was apparently invented to share pictures of furry felines, we’ll add an image of an adorable kitten to our sample index page, as shown in Figure 2.8.²

2. Image courtesy of halfmax.ru/Shutterstock.

In order to link the kitten image, we could link directly to the source of Figure 2.8 from the live Web, like this:

Click here to view code image

<img src="https://example.com/images/kitten.jpg" alt="An adorable kitten">

This practice, called hotlinking, is generally considered bad form, for reasons we’ll explain in Section 2.4.1. Instead, we’ll copy the image to the local computer, which will then be uploaded automatically when we deploy to GitHub Pages.

To do this, first create a directory called images:

$ mkdir images

Creating a separate images directory isn’t strictly necessary, but it’s useful for keeping our main project directory tidy. Next, download the image to the local disk using curl:³

3. The curl command is covered in Section 3.1 of Learn Enough Developer Tools to Be Dangerous.

Click here to view code image

$ curl -o images/kitten.jpg -L https://cdn.learnenough.com/kitten.jpg

Once the image is available on our local disk, we can use its location as the value of the src attribute. Because the image is part of the same web project as index.html, we can use the relative path to the image, like this:

Click here to view code image

<img src="images/kitten.jpg" alt="An adorable kitten">

The src attribute images/kitten.jpg will automatically be interpreted as the correct full path to the file, which locally might be

Click here to view code image

file:///Users/mhartl/repos/sample_website/images/kitten.jpg

and on the server will be something like

Click here to view code image

https://learnenough.github.io/sample_website/images/kitten.jpg

While we’re at it, we’ll add a paragraph giving some context about the creation of the World Wide Web (including a correction to the wildly inaccurate claims of its feline origins). The result appears in Listing 2.10.

Listing 2.10: An image, with a paragraph about the original web developer.
index.html

Click here to view code image

   <h1>The Learn Enough Story</h1>
   .
   .
   .
   <p>
     HTML was created by the original "web developer", computer scientist
     <a href="https://en.wikipedia.org/wiki/Tim_Berners-Lee">Tim
     Berners-Lee</a>. It's not true that Sir Tim invented HTML in order to
     share pictures of his cat, but it would be cool if it were.
   </p>

   <img src="images/kitten.jpg" alt="An adorable kitten">

   <h2>Background</h2>
   .
   .
   .

After adding the contents of Listing 2.10 to index.html, the sample index page should look something like Figure 2.9.

2.4.1 Hotlinking

We mentioned above that it’s possible to link directly to images on the Web, a practice called hotlinking. The way to do this is to use a fully qualified URL as the src parameter, like this:

Click here to view code image

<img src="https://example.com/images/example.jpg" alt="A nonexistent example">

Hotlinking isn’t usually a good practice, mainly because the image has to be at that exact spot on that exact site or it will not load, putting you at the mercy of the site’s maintainer. The person who runs the site can also be charged for the bandwidth used to serve the image, so hotlinking is considered inconsiderate as well. For these reasons, we generally recommend using local images for most applications.⁴

4. Here “local” means “local to the site” (which might be a remote server like GitHub Pages), not necessarily local to your development machine.

There are some important exceptions to the hotlinking rule, though, including an application known as Gravatar, which stands for “globally recognized avatar”. Gravatar allows you to associate standard images with particular email addresses and is used to display profile pictures on a large variety of websites, including GitHub and WordPress.⁵ Gravatar images are specifically designed for hotlinking, so in this case the practice is actually encouraged. The image could still change, but here it’s not a bug, it’s a feature,⁶ because it gives the user control over their preferred profile image—if they update their picture, the change will automatically propagate to every site using the right Gravatar URL.

5. Indeed, Gravatar was originally developed by GitHub cofounder Tom Preston-Werner, and was later acquired by Automattic, the parent company of WordPress.

6. This reference is explained in Box 2.1 of Learn Enough Developer Tools to Be Dangerous.

Gravatar URLs include a long string of hexadecimal digits (base 16, meaning 0–9 and a–f), like this:

Click here to view code image

https://gravatar.com/avatar/ffda7d145b83c4b118f982401f962ca6

Here ffda7d145b83c4b118f982401f962ca6 is a unique string based on the email address associated with the Gravatar.⁷ Gravatar URLs also support query parameters, which are additional pieces of information that come after the main URL, like ?s=150:

7. It’s calculated using something called the MD5 message-digest algorithm, which is covered in the Ruby on Rails Tutorial.

Click here to view code image

https://gravatar.com/avatar/ffda7d145b83c4b118f982401f962ca6?s=150

Query parameters come after a question mark ?, in this case s=150, which consists of a key s and a value 150.⁸ As you might be able to guess, s stands for “size”, and in this case the query parameter s=150 sets the Gravatar size to 150 pixels. (By design, Gravatars are square, so a single parameter specifies the size uniquely.)

8. Multiple query parameters are separated by the ampersand symbol &, as in https://example.com?foo=1&bar=2. If you start looking at the URLs in the address bar of your browser, you’ll see these query parameters everywhere.

Using our newfound Gravatar knowledge, let’s add avatar images to our index page under each of the Learn Enough to Be Dangerous founder bios (as added in Listing 2.8 from the exercises in Section 2.3.1). In a typical dynamic web application, such as that developed in the Ruby on Rails Tutorial (https://www.railstutorial.org/), these URLs would be calculated on the fly (https://www.railstutorial.org/book/sign_up#seca_gravatar_image) based on the users’ email addresses, but for convenience we’ll supply you with the proper URLs. The result appears in Listing 2.11. (We’ve removed the leading indentation in Listing 2.11 so that the URLs fit, but in your index.html we suggest you keep the indentation as before.)

Listing 2.11: Adding Gravatar hotlinks for the Learn Enough founders.

Click here to view code image

<h3>Michael Hartl</h3>

<img src="https://gravatar.com/avatar/ffda7d145b83c4b118f982401f962ca6?s=150"
     alt="Michael Hartl">
.
.
.

<h3>Lee Donahoe</h3>

<img src="https://gravatar.com/avatar/b65522a6f3a6899705d119d7aa232a6d?s=150"
     alt="Lee Donahoe">
.
.
.

<h3>Nick Merwin</h3>

<img src="https://gravatar.com/avatar/e2d6ce2ba5c1b6d674ae8ff2b3b45d23?s=150"
     alt="Nick Merwin">
.
.
.

The result of adding the contents of Listing 2.11 should look something like Figure 2.10, although your page may not match exactly (Section 2.4.2).

With that, our sample website’s index page has (nearly) taken its final form, so now is a good time to commit the changes and push to the live server at GitHub Pages:

Click here to view code image

$ git add -A
$ git commit -m "Add content and some images"
$ git push

The result should look something like Figure 2.11.

$ curl -o images/small_twitter_logo.png \
>      -L https://cdn.learnenough.com/small_twitter_logo.png

     .
     .
     .
     for our official email list</a> now.
   </p>

   <p>
     <a href="https://twitter.com/learnenough" target="_blank"
     rel="noopener" style="text-decoration: none;">
       <img src="FILL_IN">
     </a>
     You should follow Learn Enough on Twitter
     <a href="https://twitter.com/learnenough"
        target="_blank" rel="noopener">here</a>.
   </p>

3.1 An HTML Page About HTML

We’ll start by adding a reference page to collect some of the HTML tags we’ve learned about so far. This means creating a new file, which we can do by creating a new tab (typically with N) and then saving it as tags.html. Another method, and a personal favorite of ours, is to run touch tags.html at the command line and then use P to open it in the editor.

Once you’ve created tags.html, by whatever method, fill it with the contents of Listing 3.1.

Listing 3.1: Adding the beginning of a page on HTML tags.
tags.html

Click here to view code image

<!DOCTYPE html>
<html>
  <head>
    <title>HTML Tags</title>
    <meta charset="utf-8">
  </head>
  <body>

    <h1>Important HTML tags</h1>

    <img src="images/astronaut_tagged.jpg" alt="Tagged Astronaut">

    <p>
      This page is designed as a quick reference for some of the common tags
      covered in <a href="https://learnenough.com/html"><em>Learn
      Enough HTML to Be Dangerous</em></a>. In the process of making it, we'll
      learn how to make HTML <em>tables</em> via <code>table</code> and
      related tags.
    </p>

    <p>
      The tables below don't include all HTML tags, but they do list many of
      the most important ones.
    </p>

   </body>
</html>

Note that Listing 3.1 involves repeating the HTML skeleton from Listing 1.6, which is an inconvenient duplication of effort. It also becomes increasingly annoying as the number of pages in a site grows, especially if (as is often the case) we need to make changes to the head of the document. We’ll deal with this issue the Right Way™ in Part II (using a so-called templating system), but for now we’ll just live with the annoyance.

Listing 3.1 introduces one new tag, the minor but occasionally useful code tag:

<code>table</code>

Designed to display pieces of markup or source code, the code tag is rendered by most browsers in a monospace font, like this. (In a monospace font, all letters have the same width, which is especially convenient when lining up formatted code.)

The page defined by Listing 3.1 won’t yet render as intended because of the img tag, which currently references a nonexistent image. To fix this, download the image to the local disk:

Click here to view code image

$ curl -o images/astronaut_tagged.jpg \
>      -L https://cdn.learnenough.com/astronaut_tagged.jpg

Note that the backslash \ should be typed, but your shell will include > automatically, so don’t just copy and paste the whole thing. The result appears in Figure 3.1¹.

1. Astronaut image courtesy of svetlichniy_igor/Shutterstock; price tag image courtesy of Pretty Vectors/Shutterstock.

3.2 Tables

Now that we’ve got a basic page set up, we’ll make a list of some of the tags we’ve learned about so far. Our plan is to indicate the exact HTML code for the tag, its name, and its purpose. The result is a table of information, so to display it we’ll use the HTML table tag. Because HTML tags divide broadly into inline elements and block elements (Box 3.1), we’ll make a separate table for each type of tag.

3.2.1 Block Elements

A table is defined by opening and closing table tags, with each table row defined by the tr tag. Typically, the first row includes labels for the table’s columns via table headers, defined by the th tag, as shown in Listing 3.2.

Listing 3.2: Defining a table with headers.
tags.html

Click here to view code image

    <p>
      The tables below don't include all HTML tags, but they do list many of
      the most important ones.
    </p>

    <h2>Block Elements</h2>

    <table>
      <tr>
        <th>Tag</th>
        <th>Name</th>
        <th>Purpose</th>
      </tr>
    </table>

Because the natural layout inside a file is vertical, whereas the display is horizontal, it can be challenging to mentally map table contents to the visual result, but it gets easier with practice.

After optionally defining the table headers, tables generally consist of a series of table data cells defined by the td tag. We can get started with the content of the table by adding a row for the heading tags first introduced in Section 2.1. The result (which incidentally solves the exercise from Section 2.1.1) appears in Listing 3.3.

Listing 3.3: Adding a row of data.
tags.html

Click here to view code image

    <table>
      <tr>
        <th>Tag</th>
        <th>Name</th>
        <th>Purpose</th>
      </tr>
      <tr>
        <td><code>h1</code>–<code>h6</code></td>
        <td>headings</td>
        <td>include a heading (levels 1–6)</td>
      </tr>
    </table>

Listing 3.3 uses the code tag we saw in Listing 3.1, and also introduces –, which is a “character entity reference” for an en dash (a dash roughly the width of the letter “n”, like this: –). Because our HTML document uses the utf-8 character set (Listing 1.6), we could also use a literal en dash –, but the entity reference is common, and it’s good to know how to use both.

This is a lot to handle at once, which makes it good practice for learning to visualize the result of HTML markup. Once you have a guess in your mind’s eye, you can refresh your browser to see the result (Figure 3.3).

We’ve now seen the most important table tags, so we’re ready to fill in the table with rows for the other block-level tags we’ve seen so far. These include p and the table tags themselves.² The result appears in Listing 3.4.³

2. Technically, the td tag is more like an “inline block”, but this distinction isn’t important for our purposes.

3. Some code listings include yellow highlights for important lines, but we’ll avoid the “wall of yellow” by omitting the highlights when there are as many new lines as there are in listings like Listing 3.4.

Listing 3.4: A more complete table of HTML block elements.
tags.html

Click here to view code image

<h2>Block Elements</h2>

<table>
  <tr>
    <th>Tag</th>
    <th>Name</th>
    <th>Purpose</th>
  </tr>
  <tr>
    <td><code>h1</code>–<code>h6</code></td>
    <td>headings</td>
    <td>include a heading (levels 1–6)</td>
  </tr>
  <tr>
    <td><code>p</code></td>
    <td>paragraph</td>
    <td>include a paragraph of text</td>
  </tr>
  <tr>
    <td><code>table</code></td>
    <td>table</td>
    <td>include a table</td>
  </tr>
  <tr>
    <td><code>tr</code></td>
    <td>table row</td>
    <td>include a row of data</td>
  </tr>
  <tr>
    <td><code>th</code></td>
    <td>table header</td>
    <td>make a table header</td>
  </tr>
  <tr>
    <td><code>td</code></td>
    <td>table data</td>
    <td>include a table data cell</td>
  </tr>
</table>

There are a lot of new rows in Listing 3.4, so you can copy and paste if you want, but you’ll learn more by typing in the tags by hand. (You’ll find that it can be quite cumbersome, which is one reason many real-world tables are generated from databases using programming languages like Ruby.) The result appears in Figure 3.4.

By the way, you might notice in Figure 3.4 that the spacing around the table data cells isn’t ideal. This is exactly the kind of detail that is handled by Cascading Style Sheets (Part II).

3.2.2 Inline Elements

Now that we know how to make a basic table, we’re ready to add a new table of inline elements as well. Because inline elements by definition don’t start a new line, it’s easy to include examples of the tags along with their definitions. For instance, we can include a working example of the em tag, as shown in Listing 3.5.

Listing 3.5: A start at a table of inline tags.
tags.html

Click here to view code image

.
.
.
  <h2>Inline Elements</h2>

  <table>
    <tr>
      <th>Tag</th>
      <th>Name</th>
      <th>Purpose</th>
      <th>Example</th>
      <th>Result</th>
    </tr>
    <tr>
      <td><code>em</code></td>
      <td>emphasized</td>
      <td>make emphasized text</td>
      <td><code><em>technical sophistication</em></code></td>
      <td><em>technical sophistication</em></td>
    </tr>
  </table>

Listing 3.5 introduces the solution to the tricky problem of displaying literal angle brackets, which arranges for the browser to display, e.g., <em>technical sophistication</em> rather than technical sophistication. The way to do it is by “escaping out” < and > with the HTML character entities < (“less than”) and > (“greater than”). The result appears in Figure 3.5.

Some other inline elements we’ve encountered so far are strong, a, img, and code. Adding them to the table in Listing 3.5 is left as an exercise. Either before or after doing that exercise, we suggest adding and committing the changes and then pushing up to GitHub Pages:

Click here to view code image

$ git add -A
$ git commit -m "Add a tags page"
$ git push

    <h2>Inline Elements</h2>

    <table>
      <tr>
        <th>Tag</th>
        <th>Name</th>
        <th>Purpose</th>
        <th>Example</th>
        <th>Result</th>
      </tr>
      <tr>
        <td><code>em</code></td>
        <td>emphasized</td>
        <td>make emphasized text</td>
        <td><code><em>technical sophistication</em></code></td>
        <td><em>technical sophistication</em></td>
      </tr>
      <tr>
        <td><code>strong</code></td>
        <td>strong</td>
        <td>make strong text</td>
        <td>
          <code><strong>at least a billion people</strong></code>
        </td>
       <td>FILL_IN</td>
      </tr>
      <tr>
        <td><code>a</code></td>
        <td>anchor</td>
        <td>make hyperlink</td>
        <td>
          <code>
            <a href="https://learnenough.com/">Learn Enough</a>
          </code>
        </td>
        <td>FILL_IN</td>
      </tr>
      <tr>
        <td><code>img</code></td>
        <td>image</td>
        <td>include an image</td>
        <td>
          <code>
            <img src="https://bit.ly/1MZAFuQ" alt="Michael Hartl">
          </code>
        </td>
        <td>FILL_IN</td>
      </tr>
    </table>

3.3 Divs and Spans

Having created a new page for our HTML table experiment, we’re now ready to make a third page for our sample website. We’ll add some initial content while blocking out the structure with three new tags: header, div (for division), and span. These tags have little to no impact on the page appearance, but they help us organize the page and its contents into logical units. All three tags, and especially divs and spans, are heavily used when styling web pages using CSS (Part II). We’ll get a preview of this practice when applying inline styles in Chapter 4.

The page itself will take the form of a mock book report on the classic American whaling novel Moby-Dick (also styled as Moby Dick). As we’ll see in Chapter 4, this content will especially lend itself to styling.

The first thing we should do is create a file called moby_dick.html. Then, because it’s never wrong to include pictures of animals (even non-cats!) on web pages, we’ll include a picture of sperm whales (Figure 3.6)⁴ to go along with our report, and we’ll add an image for the book’s cover.

4. Image courtesy of willyambradberry/123RF.

In order to include the images on our web page, we need to download them to the local machine (as we did with the kitten image in Section 2.4):

Click here to view code image

$ curl -o images/sperm_whales.jpg \
>      -L https://cdn.learnenough.com/sperm_whales.jpg
$ curl -o images/moby_dick.png -L https://cdn.learnenough.com/moby_dick.png

The initial book report page is fairly long, which makes it an excellent exercise in reading and writing HTML. The result, which highlights a few especially important lines, appears in Listing 3.7. Note especially the use of target=”_blank” rel=”noopener” (introduced briefly in Section 2.3.1), which arranges to open links in a new browser tab.⁵ There is also one intentional error in Listing 3.7; catching and fixing it is left as an exercise (Section 3.3.1).

5. Or a new browser window. The exact behavior depends on the user’s browser settings.

Listing 3.7: The initial Moby-Dick book report.
moby_dick.html

Click here to view code image

<!DOCTYPE html>
<html>
  <head>
    <title>Moby Dick</title>
    <meta charset="utf-8">
  </head>
<body>

  <!-- much here to be styled, will do so in last section -->
  <header>
    <h1>A Softcover Book Report</h1>
    <h2>Moby-Dick (or, The Whale)</h2>
  </header>

  <div>
    <p>
      The <a href="https://www.softcover.io/">Softcover</a> publishing platform
      was designed mainly for ebooks like the
      <a href="https://railstutorial.org/book"><em>Ruby on Rails Tutorial</em>
      book</a> and <a href="https://learnenough.com/html"><em>Learn Enough
      HTML to Be Dangerous</em></a>, but it's also good for making more
      traditional books, such as the novel <em>Moby-Dick</em> by Herman
      Melville (sometimes written as <em>Moby Dick</em>). We present below a
      short and affectionately irreverent book report on this classic of
      American literature.
   </p>
  </div>

  <a href="https://commons.wikimedia.org/wiki/File:Sperm_whale_pod.jpg">
    <img src="images/sperm_whales.jpg">
  </a>
    <div>

      <h3>Moby-Dick: A classic tale of the sea</h3>

      <a href="https://www.softcover.io/read/6070fb03/moby-dick"
         target="_blank" rel="noopener">
        <img src="images/moby_dick.png" alt="Moby Dick">
      </a>

      <p>
        <a href="https://www.softcover.io/read/6070fb03/moby-dick"
           target="_blank" rel="noopener">
          <em>Moby-Dick</em></a>
          by Herman Melville begins with these immortal words:
      </p>

     <blockquote>
       <p>
         <span>Call me Ishmael.</span> Some years ago–never mind how long
         precisely–having little or no money in my purse, and nothing
         particular to interest me on shore, I thought I would sail about a
         little and see the watery part of the world. It is a way I have of
         driving off the spleen and regulating the circulation.
      </p>
     </blockquote>

     <p>
       After driving off his spleen (which <em>can't</em> be good for you),
       Ishmael then goes on in much the same vein for approximately one
       jillion pages. The only thing bigger than Moby Dick (who—<em>spoiler
       alert!</em>—is a giant white whale) is the book itself.
     </p>
   </div>
 </body>
</html>

In Listing 3.7, the header tag contains the h1 and h2 tags, and its importance will become apparent only when we add inline styles in Chapter 4. For now, what’s important is that it’s an abstract semantic tag used to label a part of the page and has no immediate effect on the page’s appearance.

Likewise, the div tag sets the page divisions apart, but won’t have any effect until Chapter 4. We’ve also wrapped the iconic first line of Moby-Dick, “Call me Ishmael.”, in a span tag in anticipation of styling it in Chapter 4. (The main difference between the div and span tags is that div is a block element, whereas span is an inline element (Box 3.1).) Finally, we’ve introduced the blockquote tag for quoting blocks of text.

In addition to illustrating the header, div, and span tags, Listing 3.7 also shows an HTML comment, which appears as follows:⁶

6. In Atom, you can toggle HTML comments using / (“Command-slash”), which (as noted in Section 7.2 of Learn Enough Developer Tools to Be Dangerous) works for source code as well. Because the text editor infers the file type from the filename extension (or from the “shebang line” #!), we can use / to comment things out without having to remember the exact syntax for the file type we happen to be editing.

Click here to view code image

<!-- much here to be styled, will do so in last section -->

This line, which foreshadows the styling steps in Chapter 4, is ignored by the browser, and is not visible on the rendered page, as (not) seen in Figure 3.7.⁷

7. The comment is sent over the wire to the browser, though, and is visible to anyone inspecting the HTML source of our page.

3.4 Lists

As part of our mini-report on Moby-Dick, we’d like to include a couple of lists with some of our observations about the book. As we’ll see, HTML lists come in two basic types.

The first list will highlight our top three favorite things about Moby-Dick. Because we want these to be in rank-order, we’ll use the ordered list tag ol:

Click here to view code image

<h4>Our top 3 favorite things about Moby Dick</h4>

<ol>
  <li>Vengeful whale</li>
  <li>Salty sailors</li>
  <li>The names "Queequeg" and "Starbuck"</li>
</ol>

Here the li tag indicates a list item (also called a list element), and the result will be numbered in sequence:

1. …
2. …
3. …

The second list will contain some other miscellaneous musings. Because the order isn’t important, we’ll use the unordered list tag ul, together with the same li list element tag used for ordered lists:

Click here to view code image

<h4>Other things about Moby Dick</h4>

<ul>
  <li>
    Chapter after chapter (after chapter) of meticulous detail about whaling
  </li>
  <li>
    The story pretty much
    <a href="https://en.wikipedia.org/wiki/Essex_(whaleship)"
       target="_blank" rel="noopener">happened in real life</a>
  </li>
  <li>Mad sea captains are fun</li>
</ul>

As we’ll see in a moment, unordered list elements are styled as bullet points by default:

• …
• …
• …

They are much more useful than this, though, and in practice unordered lists are used for significantly more than just making bullet points (as we’ll see in Part II).

Putting these two lists together and adding them to the end of moby_dick.html gives Listing 3.8.

Listing 3.8: Adding lists to our Moby-Dick book report.
moby_dick.html

Click here to view code image

    <h4>My top 3 favorite things about Moby Dick</h4>

    <ol>
      <li>Vengeful whale</li>
      <li>Salty sailors</li>
      <li>The names "Queequeg" and "Starbuck"</li>
    </ol>

    <h4>Other things about Moby Dick</h4>

    <ul>
      <li>
        Chapter after chapter (after chapter) of meticulous detail about
        whaling
      </li>
      <li>
        The story pretty much

        <a href="https://en.wikipedia.org/wiki/Essex_(whaleship)"
           target="_blank" rel="noopener">happened in real life</a>
      </li>
      <li>Mad sea captains are fun</li>
    </ul>
  </div>
 </body>
</html>

The result appears in Figure 3.8, which incidentally also shows the rendered block-quote that’s not quite visible in Figure 3.7.

3.5 A Navigation Menu

Before moving on to styling our book report page in Chapter 4, we’ll add a component common to most sites on the Web, yet one whose origins are mysterious: a navigation menu with links to all the pages on the site (Box 3.2). In the process, we’ll learn how to make links to pages on the current site instead of always linking to external websites. The navigation menu will also give us another chance to see how cumbersome it is to make websites without a templating system.

We’ll start by adding a div containing three links (one for each navigation element) to the index page (Listing 3.9). Note that we’ve adopted the common convention of referring to the index page as “Home”.

Listing 3.9: Adding navigation links.
index.html

Click here to view code image

<!DOCTYPE html>
<html>
  <head>
    <title>Learn Enough to Be Dangerous</title>
    <meta charset="utf-8">
  </head>
  <body>

    <div>
      <a href="index.html">Home</a>
      <a href="moby_dick.html">Moby Dick</a>
      <a href="tags.html">HTML Tags</a>
    </div>

    <h1>The Learn Enough Story</h1>

We see from Listing 3.9 that the way to link to a local page simply involves setting the href attribute equal to the path to the file, which works exactly the same way as an img tag’s src attribute (Section 2.4):

Click here to view code image

<a href="tags.html">HTML Tags</a>

The result appears in Figure 3.9.

We can add the same menu to the HTML tags page with the markup in Listing 3.10. The result appears in Figure 3.10.

Listing 3.10: Adding the navigation menu to the HTML tags page.
tags.html

Click here to view code image

<!DOCTYPE html>
<html>
  <head>
    <title>HTML Tags</title>
    <meta charset="utf-8">
  </head>
  <body>

    <div>
      <a href="index.html">Home</a>
      <a href="moby_dick.html">Moby Dick</a>
      <a href="tags.html">HTML Tags</a>
    </div>

    <h1>Important HTML tags</h1>

Adding the menu to the page on Moby-Dick is left as an exercise.

By the way, you may have noticed that it would probably be more natural to order the navigation in order of the pages’ introduction, i.e., Home, Tags, Moby Dick. Changing this order is also left as an exercise, mainly so that you feel the pain of making the same change on three different pages—a pain that is alleviated by the templating systems covered in Chapter 9. Either before or after doing that exercise, we suggest adding and committing the changes and then pushing up to GitHub Pages:

Click here to view code image

$ git add -A
$ git commit -m "Add a Moby Dick page and a menu"
$ git push

4.1 Text Styling

As mentioned in Section 3.3, our design efforts will focus on the Moby-Dick book report page, which stands to gain the most from changing the default HTML styling. We’ll begin by adding a little styling to the quotation from the first paragraph of Moby-Dick. Recall from Listing 3.7 that the quotation uses the blockquote tag, which is set apart from the surrounding text by extra space and indentation (Figure 4.1).

To make the quotation stand out even more, let’s change the font style to italics while increasing the font size to 20 pixels (20px). The way to do this is with the style attribute, which can be added to virtually any HTML tag. In this case, we’ll change the font-style and the font-size as follows:

Click here to view code image

style="font-style: italic; font-size: 20px;"

Note that the styling rules after style= are a single string of characters, with each individual style separated from the others by a semicolon ;. (The final semicolon isn’t technically necessary, but including it is a good practice since it lets us add additional styles later on without having to remember to add a semicolon.)

Taking this idea and editing moby_dick.html leads to the HTML shown in Listing 4.1. The result appears in Figure 4.2.

Listing 4.1: Styling the blockquote.
moby_dick.html

Click here to view code image

  <blockquote style="font-style: italic; font-size: 20px;">

Next, we’ll add some styling to the famous first line “Call me Ishmael.” We’ll first revert the font style back to normal (which is how you emphasize text when the surrounding text is already in italics). Then we’ll make the font even bigger than the 20px used for the rest of the quotation, while also making it bold. Finally, we’ll change the color to an attention-grabbing red.

Ordinarily, there would be no way to style just the line “Call me Ishmael.” If we had written it as

Click here to view code image

Call me Ishmael. Some years ago…

at this point we’d be out of luck. Recall from Listing 3.7, though, that the opening line is wrapped in a span tag:

Click here to view code image

<span>Call me Ishmael.</span> Some years ago…

The reason for this is that we correctly anticipated wanting to style it later on. (In practice we can’t always anticipate such things, but of course we can wrap the relevant text in a span tag as needed.)

Although the span tag doesn’t really do anything by itself, we can add styles to it, as follows:

Click here to view code image

<span style="font-style: normal; font-size: 24px; font-weight: bold;
color: #ff0000;">Call me Ishmael.</span>

Here we’ve combined font-style, font-size, font-weight, and color to obtain the results outlined above. These are but a few of the many style properties available, which you can learn about at sites like w3schools (https://www.w3schools.com/cssref/). Meanwhile, the color ff0000 is a hexadecimal code for red, as discussed in Box 4.2.

Including the styles above in moby_dick.html gives us the code in Listing 4.2, with the result shown in Figure 4.3.

Listing 4.2: Adding style to the opening span.
moby_dick.html

Click here to view code image

<blockquote style="font-style: italic; font-size: 20px;">
  <p>
    <span style="font-style: normal; font-size: 24px; font-weight: bold;
    color: #ff0000;">Call me Ishmael.</span>
    Some years ago–never mind how long precisely–having little or
    no money in my purse, and nothing particular to interest me on shore,
    I thought I would sail about a little and see the watery part of the
    world. It is a way I have of driving off the spleen and regulating the
    circulation.
  </p>
</blockquote>

As a final change, we’ll align the text of the book report headers so that it’s centered in the page. The way to do this is with the text-align property, as shown in Listing 4.3. (Note that Listing 4.3 also removes the comment from Listing 3.7 since it’s now obsolete.)

Listing 4.3: Centering the headings.
moby_dick.html

Click here to view code image

<header>
  <h1 style="text-align: center;">A Softcover Book Report</h1>
  <h2 style="text-align: center;">Moby-Dick (or, The Whale)</h2>
</header>

The result appears in Figure 4.4.

4.2 Floats

Now that we’ve learned how to move text around, let’s look at how to adjust the placement of other elements. We’ll start by shrinking the size of the cover image down a little, and then we’ll arrange for the text to flow around it as if it were part of the paragraphs and blockquote.

We’ll start by adding the height attribute to the img tag to restrict the height to 200 pixels:

Click here to view code image

<img src="images/moby_dick.png" alt="Moby Dick" height="200px">

Several caveats are in order here. First, although inline resizing is still fairly common, using CSS is the best practice. Second, resizing the image this way (whether inline or with CSS) affects only the image display, and the entire image still needs to be downloaded from the web server, so this technique should be used only for fairly minor resizings.¹ (If you’ve ever visited a web page where a seemingly tiny image takes forever to load, this is probably the reason why.) Finally, if you go this route you should use either height or width, but not both, as the combination forces the browser to attempt to respect both numbers, which can result in weird image-resizing effects (Figure 4.5).

1. If you need to resize the image itself and don’t have access to Photoshop, you can use the free Skitch (https://evernote.com/products/skitch) utility for resizing, cropping, and simple annotation.

In order to get the text to flow around the image, we need to use a style technique called floating. The idea is that when you set an element to “float” to the left or right (there is no center), all the inline content around it will flow around the floated element. To see this in action, all we need to do is add style=”float: left;” to the image attributes:

Click here to view code image

<img src="images/moby_dick.png" alt="Moby Dick" height="200px"
style="float: left;">

Inserting this into the book report page gives Listing 4.4, with the result shown in Figure 4.6.

Listing 4.4: Resizing and floating an image.
moby_dick.html

Click here to view code image

   <h3>Moby-Dick: A classic tale of the sea</h3>

   <a href="https://www.softcover.io/read/6070fb03/moby-dick"
      target="_blank" rel="noopener">
     <img src="images/moby_dick.png" alt="Moby Dick" height="200px"
     style="float: left;">
   </a>

In Figure 4.6, the image is effectively treated like text, with the normal text now flowing up and to its side. We’ll see in Section 4.5 that the float attribute also arranges for the text to flow past the image as well.

4.3 Applying a Margin

Even though we’ve floated the image, the page still looks a little weird, with the text smashed up against the book cover. To make it look better, we’ll add a margin of empty space to the right of the image.

Margins are one of three styles that can be applied to the imaginary boxes that contain HTML content, the others being padding (empty space inside the box) and borders (a line around the box). We’ll talk more about these styles in the context of the box model covered in Chapter 8 of Part II, but we can accomplish our immediate goal by applying a margin using inline styling. (We’ll see an example of padding in Section 4.5.)

We’ll start with the simplest kind of margin declaration, which looks like margin: 40px;:

Click here to view code image

<img src="images/moby_dick.png" alt="Moby Dick" height="200px"
style="float: left; margin: 40px;">

If we add this to the img tag (Listing 4.5), everything surrounding the image moves 40 pixels in each direction, as shown in Figure 4.7.

Listing 4.5: Adding an image margin.
moby_dick.html

Click here to view code image

  <h3>Moby-Dick: A classic tale of the sea</h3>

  <a href="https://www.softcover.io/read/6070fb03/moby-dick"
     target="_blank" rel="noopener">
    <img src="images/moby_dick.png" alt="Moby Dick" height="200px"
    style="float: left; margin: 40px;">
  </a>

Figure 4.7 shows that we’ve gotten closer to our goal by putting some space between the text and the image, but the styling still isn’t quite what we want. The reason is that writing margin: 40px; applies the margin in all directions, but we really only want the margin on the right side of the image, to separate it from the text.

The most general way to control where the margin goes is to give the margin attribute four values, corresponding to the top, right, bottom, and left of the box (Figure 4.8).

For example, to get margins of 40, 30, 20, and 10 pixels going around an image (clockwise from the top), we could use this style attribute:

Click here to view code image

<img src="…" style="margin: 40px 30px 20px 10px;">

In the present case, we want only a right margin, so we can set the other three sides to 0px (or just 0 for short):²

2. We could use the attribute style="margin-right: 40px;" to achieve the same effect, but specifying all four margins is the dominant convention and so is worth learning.

Click here to view code image

<img src="images/moby_dick.png" alt="Moby Dick" height="200px"
style="float: left; margin: 0 40px 0 0;">

Applying this to the full source of the book report page gives Listing 4.6.

Listing 4.6: Adding only a right margin.
moby_dick.html

Click here to view code image

<h3>Moby-Dick: A classic tale of the sea</h3>

<a href="https://www.softcover.io/read/6070fb03/moby-dick"
   target="_blank" rel="noopener">
  <img src="images/moby_dick.png" alt="Moby Dick" height="200px"
  style="float: left; margin: 0 40px 0 0;">
</a>

The result of Listing 4.6 shows exactly the result we want, with a margin applied only on the right, as seen in Figure 4.9.

4.4 More Margin Tricks

There are a couple more margin tricks worth mentioning, both of which we can immediately put to good use. First, in addition to the shorthand margin: 40px (with only one value), it’s possible to include only two values:

margin: 20px 40px;

As illustrated in Figure 4.8, this syntax sets the top and bottom margins to 20px and the left and right margins to 40px, so it is equivalent to

margin: 20px 40px 20px 40px;

This shorthand also works with just three values, like this: margin: 20px 10px 40px;. This is missing the last value, which (as seen in Figure 4.8) is the left margin. In this case, it will be filled in automatically from its opposite across the box (in this case, 10px).

We can apply this to the header for the book report page by adding a bottom margin via margin: 0 0 80px, as shown in Listing 4.7.

Listing 4.7: Centering the book report headers.
moby_dick.html

Click here to view code image

  <header style="text-align: center; margin: 0 0 80px;">
    <h1>A Softcover Book Report</h1>
    <h2>Moby-Dick (or, The Whale)</h2>
  </header>

Note that we’ve also taken this opportunity to hoist the style text-align: center into the header tag. The result appears in Figure 4.10.

The second margin trick is the use of auto, which inserts a margin with a size that is automatically the same on all relevant sides. Its most common application is probably in the rule

margin: 0 auto;

which arranges for no top or bottom margin and for automatic margins on the left and right. The result of equal left and right margins is that the element is centered, which is especially useful for elements like images that can’t be centered using the text-align: center; rule we saw in Listing 4.3.

One restriction of margin: 0 auto; is that it works only on block elements, but recall from Box 3.1 that the img tag is an inline element. We can fix this with the style display: block;, which overrides the default. Putting this together with the margin rule leads to Listing 4.8, with the result shown in Figure 4.11.

Listing 4.8: A centered image.
moby_dick.html

Click here to view code image

  <a href="https://commons.wikimedia.org/wiki/File:Sperm_whale_pod.jpg">
    <img src="images/sperm_whales.jpg"
    style="display: block; margin: 0 auto;">
  </a>

4.5 Box Styling

So far, the changes we’ve made have had a relatively minor impact on the appearance of the book report page. In this section, we’ll see how a set of only four style rules can make a surprisingly big difference.

Recall from Listing 3.7 that we wrapped the bulk of the report in a div tag, which defines a block element that doesn’t get any default styling from the browser, thereby making it perfect to use as a wrapper for styling other content. In this case, we’ll use the width style to restrict the size of the main report to 500 pixels, and it turns out this lets us use the automatic margin trick from Section 4.4 to center it using margin: 20px auto; (thereby also putting a 20-pixel margin on the top and bottom). Finally, we’ll combine a padding rule with a change in the background-color using the hexadecimal color convention covered in Box 4.2. The resulting style rules appear in Listing 4.9.

Listing 4.9: Adding styling to the book report box.
moby_dick.html

Click here to view code image

  <div style="width: 500px; margin: 20px auto; padding: 30px;
  background-color: #fafafa;">
    <h3>Moby-Dick: A classic tale of the sea</h3>

Comparing the before and after (Figure 4.12) shows what a difference a few style rules can make.

As we see in Figure 4.12, the report content has now been set apart from the rest of the page in a styled box.

To recap what happened, we set a width for the box, and because of this we were able to set the left and right margins to auto. Then we added padding to the box, which pushed the content inside away from the edges. (Investigating the difference between padding and margins is left as an exercise (Section 4.5.1).) We also added a light gray background color with the hexadecimal code #fafafa (Box 4.2). (Don’t worry about trying to visualize the color corresponding to a hex code; that’s what color pickers are for.) Finally, because of the narrower width, the text of the Moby-Dick quotation now flows around the floated cover image, thereby fulfilling the promise made at the end of Section 4.2.

  <h1>The Learn Enough Story</h1>
  .
  .
  .
  <img src="images/kitten.jpg" alt="An adorable kitten">

  <TAG>Quotations</TAG>

  <p>
    In addition to hosting most of the world's supply of kitten videos, the
    Web is also full of inspiring quotes, perhaps none more so than this one:
  </p>

  <blockquote style="padding: 2px 20px; background: #FILL_IN;">
    <p>
      <em>Don't believe every quote you read on the Internet.</em>
      <br>
      —Abraham Lincoln
    </p>
  </blockquote>

4.6 Navigation Styling

As a final change to our sample website, we’ll make a change across all three pages by adding styling to the navigation menu added in Section 3.5. In the process, we’ll yet again feel the pain of having to make the same change in several places, further preparing us to appreciate the value of the template system developed in Part II.

To style the nav menu, we’ll first move it from the top left of the page to the more conventional top right. This will involve adding a style rule to the div tag that wraps the whole menu (Listing 3.9). At the same time, we’ll add a left margin to the second and third nav links in order to improve the spacing. The changes to the book report page appear in Listing 4.11, and the result appears in Figure 4.14.

Listing 4.11: Styling the navigation menu on the book report page.
moby_dick.html

Click here to view code image

  <div style="text-align: right;">
    <a href="index.html">Home</a>
    <a href="tags.html" style="margin: 0 0 0 10px;">HTML Tags</a>
    <a href="moby_dick.html" style="margin: 0 0 0 10px;">Moby Dick</a>
  </div>

Of course, we’re not done yet, as we need to make the same edits to the nav menu on the Home page (Listing 4.12) and HTML Tags page (Listing 4.13).

Listing 4.12: Styling the navigation menu on the Home page.
index.html

Click here to view code image

  <div style="text-align: right;">
    <a href="index.html">Home</a>
    <a href="tags.html" style="margin: 0 0 0 10px;">HTML Tags</a>
    <a href="moby_dick.html" style="margin: 0 0 0 10px;">Moby Dick</a>
  </div>

Listing 4.13: Styling the navigation menu on the HTML Tags page.
tags.html

Click here to view code image

  <div style="text-align: right;">
    <a href="index.html">Home</a>
    <a href="tags.html" style="margin: 0 0 0 10px;">HTML Tags</a>
    <a href="moby_dick.html" style="margin: 0 0 0 10px;">Moby Dick</a>
  </div>

The results on the nav menu are exactly the same as shown in Figure 4.14. This is not surprising given that the changes represented by Listing 4.11, Listing 4.12, and Listing 4.13 are all identical. This sort of repetition is cumbersome and error-prone— definitely a Bad Thing. As mentioned several times before, we’ll solve this problem with a templating system in Part II.

4.7 A Taste of CSS

In this section, we’ll get a first taste of Cascading Style Sheets (CSS),³ using the inline styles from index.html as our example. We’ll break the transition from inline styles to CSS into two steps: First, we’ll move the inline styles into an internal stylesheet (Section 4.7.1); second, we’ll move the internal style rules into an external stylesheet (Section 4.7.2). The result will be a self-contained and centralized location for our page’s styling.

3. The words “style” and “sheet” are conventionally written as two words—Style Sheet—only in the context of spelling out the meaning of “CSS”. Otherwise, they are generally combined into one word, “stylesheet”.

<!DOCTYPE html>
<html>
  <head>
    <title>Learn Enough to Be Dangerous</title>
    <meta charset="UTF-8">

    <style>

    </style>
  </head>

  <div style="text-align: right;">
    <a href="index.html">Home</a>
    <a href="tags.html" class="nav-spacing">HTML Tags</a>
    <a href="moby_dick.html" class="nav-spacing">Moby Dick</a>
  </div>

  <style>
    .nav-spacing {
      margin: 0 0 0 10px;
    }
  </style>

  <div class="nav-menu">
    <a href="index.html">Home</a>
    <a href="tags.html" class="nav-spacing">HTML Tags</a>
    <a href="moby_dick.html" class="nav-spacing">Moby Dick</a>
  </div>

  <style>

    .nav-menu {
      text-align: right;
    }
    .nav-spacing {
      margin: 0 0 0 10px;
    }
  </style>

  <div id="main-nav" class="nav-menu">
    <a href="index.html">Home</a>
    <a href="tags.html" class="nav-spacing">HTML Tags</a>
    <a href="moby_dick.html" class="nav-spacing">Moby Dick</a>
  </div>

$ mkdir css
$ touch css/main.css

.nav-menu {
  text-align: right;
}
.nav-spacing {
  margin: 0 0 0 10px;
}

<!DOCTYPE html>
<html>
  <head>
    <title>Learn Enough to Be Dangerous</title>
    <meta charset="UTF-8">
    <link rel="stylesheet" href="css/main.css">
  </head>

$ git add -A
$ git commit -m "Refactor inline styles into a stylesheet"

<h2 id="founders">Founders</h2>

4.8 Conclusion

Congratulations! You now know enough HTML to be dangerous. All that’s left is to commit (in case you’ve made changes in Section 4.7.3) and deploy the final sample website:

Click here to view code image

$ git commit -am "Finish the sample website"
$ git push

The result is a full website running in a production environment (Figure 4.16).

For reference, summary tables of all the block-level tags and inline tags appear in Table 4.1 and Table 4.2, respectively.

At this point, you’ve got a solid foundation in the basics of HTML. This means you have the perfect preparation for learning how to make a professional-grade website with attractive styling and fancy page layouts. In other words, you’re now ready for Part II!

5.1 You’re a Front-End Developer

CSS isn’t the kind of language that’s useful to learn in little half-steps—the part that people find difficult is dealing with handling styling when they are deep into creating an honest-to-goodness website with many levels of complexity. The real skill comes in knowing how to plan for a multipage site that uses a bunch of different snippets of code³ placed into a flexible layout that organizes content and data in a useful way.

3. Technically, HTML and CSS are markup and not code, but we’ll sometimes use the latter term as a catchall, especially when discussing principles from coding (such as avoiding repetition) that apply as much to HTML and CSS as they do to programming languages like JavaScript or Ruby.

There are already many sites (like the Mozilla Developer Network CSS Reference) that exhaustively document every CSS property, so going over each and every option from the specification would just be a duplication of effort. Instead, Learn Enough CSS & Layout to Be Dangerous is designed to complement such reference works by showing you how CSS applies to the design of a real website. The resulting narrative explanation gives you the context necessary to understand and apply CSS documentation—especially when combined with a little technical sophistication (Box 5.1).

The important thing at this point in your progress as a developer is to start learning how styling and layout concepts work together, how HTML and CSS combine to make a layout that is actually useful, and how to use some sort of system that allows you to avoid repeating sections of the site or styling on multiple pages (Box 5.2). Doing otherwise would make you an expert at changing text color and size, but you’d have no chance of applying the knowledge you’ve gained to a real-world scenario. In fact, by learning CSS in a holistic way, you’ll not just be getting an introduction to styling—this tutorial is also going to be your first introduction to the world of front-end development.

5.2 CSS Overview and History

CSS takes the form of plain-text declarations inserted into an HTML or CSS file using a text editor (https://www.learnenough.com/text-editor). A typical series of CSS declarations might look like Listing 5.1. (You are not expected to understand these styles at this point.)

Listing 5.1: Typical CSS declarations.

Click here to view code image

body {
  color: black;
}

p {
font-size: 1em;
}

p.highlighted {
  font-size: 1.5em;
  background: yellow;
}

The “Cascading” part of Cascading Style Sheets refers to the way the defined styles flow, or “cascade”, down from element to element on a page based on a few factors like which declaration came first, whether an element is the child of a parent element that has styles applied to it, or the strength of the declaration (more on this in Section 6.3). This inheritance of style (from the top levels to elements below) happens so that we as developers can avoid having to define how every single element should look. For example, if we changed the color in the body tag in Listing 5.1, that change would cascade down and change the color attribute on every interior element as well.

The “Style Sheet” part of the name (sometimes written as the single word stylesheet) refers to how CSS allows developers to collect all the style declarations in a separate section of the page (called an internal stylesheet), or place them into an external file (called, you guessed it, an external stylesheet). External stylesheets are loaded onto the page as a link in the head section of the HTML. (We’ll learn how to do this ourselves in Chapter 9.) The result is that we end up separating the code that defines how something looks (or is positioned) from the actual content—all of which makes for simpler and more maintainable code.

5.2.2 How Did CSS Develop?

In the beginning, content on the Internet was simply plain text. Then, as methods for organizing content started to come into existence (such as HTML around 1990), a number of methods sprang up to affect the appearance and layout of the data.

At first, many styling solutions that affected how the page looked would be set by individual users’ browser preferences rather than by the creator of the page. As the complexity of the web increased, it became increasingly obvious that there should be a way for the owner of a site to at least suggest how a page should look, rather than leaving the appearance up to each individual browser.

Lots of interesting suggestions were put forward that never got widely adopted, usually because the proposed styling was overly complicated or used a totally nonintuitive structure:

• Robert Raisch developed RRP, which used arcane two-character style declarations and was fairly unreadable.

• Pei-Yuan Wei created the ViolaWWW browser and a styling system called PWP, which introduced nesting styles and external stylesheets, but it was only released for Unix operating systems and never really caught on.

• FOSI was created for an HTML precursor called SGML, and it worked by adding complicated tags on the page around content (not good).

• DSSSL allowed for complex declarations and was more of a programming language with styling attached, but it had a complicated syntax that made it overly complex for styling.

In short, there was a real Cambrian explosion of proposed standards to make the web pretty, and while some of these systems ended up contributing elements to what became CSS, none of them are direct ancestors (Figure 5.3).⁵

5. Image courtesy of Liliya Butenko/Shutterstock.

About five years after the introduction of HTML, Håkon Lie (working with Bert Bos) put forward a styling system proposal in December of 1996 called CHSS (Cascading HTML Style Sheets). As you might expect, the original proposal has some details that are no longer present in the language, but in his doctoral thesis Håkon Lie simplified the specification into something that more closely resembles modern CSS. Eventually, the concept was adopted by the World Wide Web Consortium (W3C) as the system for styling web content.

Although it represented a big step forward, creating a specification is only half the battle—browsers have to support the standard for it to be of any use to the end-user.

No browser even partially supported CSS until 1997, and there wasn’t full support of the standard in any one browser until March of 2000—partially because browser makers still had their own ideas for how to accomplish styling, and partially because many browsers supported non-standard HTML tags (we’re looking at you, Internet Explorer…).

Each browser handled CSS in its own idiosyncratic way for a long time, and anyone who has been working in front-end development for a while can tell you how maddeningly difficult it was to style a website so that it looked the same across browsers. Microsoft’s Internet Explorer was by far the biggest problem (Figure 5.4), and we can only imagine the number of people who gave up on the world of web design and development thanks to horrific CSS support in early versions of IE.⁶

6. If you are ever asked to develop something that can work in Internet Explorer 6 or 7, just laugh and walk away. Trying to make a site work on those browsers just isn’t worth it, and thankfully they are finally disappearing from the world.

The differences between implementations of CSS in different browsers remained significant until just a few years ago, with the rise to dominance of the WebKit browsers (Google Chrome and Apple Safari) and Gecko-powered Mozilla Firefox.

So when reading this tutorial, just keep in mind that styling the Web was a complete and utter mess until very recently—about 15 years after the initial release of the CSS spec in 1997.

5.2.3 The Bog of Eternal Subjectivity

One last bit of meta-information before we jump in and start styling: deciding how to actually implement CSS on a given page can be a confusing mess. Whereas Part I was a little more prescriptive in nature, with many cases where there was only one right way to do things, we are now going to be venturing into places where there is often no right answer. When designing websites with CSS, many solutions to a problem typically exist, which means subjective judgment is the rule rather than the exception (Figure 5.5).⁷

7. Image courtesy of Historic Collection/Alamy Stock Photo.

Helping you navigate this mess is where we come in.

Oh, and to make this all a little more fun, you may recall from Box 5.3 that every browser implements some parts of the CSS standard in its own slightly different manner, so you can never be absolutely certain that something will look the same to different users if they are using different browsers… to say nothing of how something will look on different screen sizes and resolutions for different operating systems (Chapter 13).

You have to get used to the idea that no site is going to be exactly the same when viewed by different people. You’ll learn to design (or implement other people’s designs) in a way that allows room for CSS’s inherent ambiguity. Unlike the tightly constrained world of print design, getting things to look exactly the same in every browser and on every operating system is just something you have to give up worrying about.

Additionally, when talking about which CSS rules to use when styling a site or creating a layout, best practices tend to move in fads, or are influenced by the subjective opinion of the developers who worked on a project before you. For example, as discussed in Section 5.5, elements on the page frequently need to be assigned classes or ids, and the way that names are picked is entirely up to the person writing the code. As you might guess (if you know many developers or designers), people have lots of strong opinions on how you should be naming things—a classic holy war situation.⁸

8. The notion of a technological “holy war” is discussed in Box 5.4 of Learn Enough Developer Tools to Be Dangerous.

The most important thing is to be consistent. If you start a project and do things one way, make sure to keep following the same conventions for the life of the project. Or, if you decide to make a drastic change, spend the next couple of days updating all your old code, for the sake of future developers (including yourself). Keep an eye out in this tutorial for “Style Note” boxes that have tips on what the current best practices are for different uses of CSS.

5.3 Sample Site Setup

Now that we’ve got an overview of the purpose and origins of CSS, it’s time to start looking at some concrete examples. The initial styling rules will necessarily be simple, so it’s important to have patience while we lay this crucial foundation for the working website (with layout) that we’ll be developing starting in Chapter 9.

We’ll start by creating a new project in the repos folder using the same basic mkdir command covered in Section 1.3 (Listing 5.2).⁹

9. Note for Mac users: Although it shouldn’t matter in Learn Enough CSS & Layout to Be Dangerous, it is recommended that you use the Bourne-again shell (Bash) rather than the default Z shell to complete this tutorial. To switch your shell to Bash, run chsh -s /bin/bash at the command line, enter your password, and restart your terminal program. Any resulting alert messages are safe to ignore. See the Learn Enough blog post “Using Z Shell on Macs with the Learn Enough Tutorials” (https://news.learnenough.com/macos-bash-zshell) for more information.

Listing 5.2: Adding the folder for our sample project.

Click here to view code image

$ cd                                    # cd to the home directory
$ mkdir -p repos/<username>.github.io   # Make site directory
$ cd repos/<username>.github.io         # cd into new directory

Note that we’ve used a special directory name that corresponds to the main GitHub Pages site for your account:

<username>.github.io

In Listing 5.2, <username> should be replaced with your GitHub username, so the full URL should look something like learnenough.github.io.

GitHub Pages actually supports serving sites out of subdirectories, like learnenough.github.io/sample_css, but unfortunately this solution fails if you have additional subdirectories in your site, such as learnenough.github.io/sample_css/gallery. The reason is that if you include files and images in one subdirectory (e.g., sample_css), there’s no natural way to include the same files and images in further subdirectories (e.g., sample_css/gallery). Since our sample site will eventually have exactly this kind of structure (Section 10.4), we’ve opted to use the root Pages domain. An even better solution is to use a custom domain, which lets you host your GitHub Pages site at a URL like www.example.com; this is the subject of Part III.

To get our site started, we’ll also create an index.html file using the touch command (as discussed in Section 1.3), as shown in Listing 5.3.

Listing 5.3: Adding a blank index.html.

Click here to view code image

$ touch index.html    # Create an empty index file

Inside the new folder, use your favorite text editor to open the newly created index.html file and paste in the markup shown in Listing 5.4. For convenience, the contents of Listing 5.4 and all other code listings in this tutorial are available online at the following URL:

Click here to view code image

https://github.com/learnenough/learn_enough_html_css_and_layout_code_listings

Listing 5.4: The initial HTML for our site.
index.html

Click here to view code image

<!DOCTYPE html>
<html>
  <head>
    <title>Test Page: Don't Panic</title>
    <meta charset="utf-8">
    <style>

    </style>
  </head>
  <body>
    <h1>I'm an h1</h1>
    <ul>
      <li>
        <a href="https://example.com/" style="color: red;">Link</a>
      </li>
      <li>
        <a href="https://example.com/" style="color: red;">Link</a>
      </li>
      <li>
        <a href="https://example.com/" style="color: red;">Link</a>
      </li>
    </ul>
    <h2>I'm an h2</h2>
    <div style="border: 1px solid black;">
      <a href="https://example.com/" style="color: green;">I'm a link</a>
    </div>
    <div style="border: 1px solid black;">
      <a href="https://example.com/" style="color: green;">I'm a link</a>
    </div>
    <div style="border: 1px solid black;">
      <a href="https://example.com/" style="color: green;">I'm a link</a>
    </div>
    <div style="border: 1px solid black;">
      <a href="https://example.com/" style="color: green;">I'm a link</a>
    </div>
  </body>
</html>

When you open that HTML document in your browser (if you aren’t sure how to do that, refer back to Section 1.4), you’ll see a series of three red links, some headers, and a series of green links in boxes (Figure 5.6). This will be our initial test page.

Note: Due to various slight differences between browsers, browser window sizes, etc., your results may not always match the screenshots exactly, so small discrepancies are not a cause for concern. As we’ll emphasize throughout this tutorial, it’s important to focus on achieving good-enough results without chasing the unreachable goal of pixel-perfection.

As in Chapter 1, we’ll deploy our new website immediately to production, which is a good habit to cultivate. First, you’ll need to create a new project at GitHub, using the steps shown in Section 1.3, which in this case looks like Figure 5.7.

Once you’ve finished the steps needed to create the repository, initialize and deploy it using the commands shown in Listing 5.5.

Listing 5.5: Deploying the initial site to GitHub Pages.

Click here to view code image

$ git init
$ git add -A
$ git commit -m "Initialize repo"
$ git remote add origin <repo url>
$ git push -u origin main

If you find the sequence of commands in Listing 5.5 challenging instead of familiar, it’s probably a good idea to review Learn Enough Git to Be Dangerous (https://www.learnenough.com/git) and Section 1.3. (Confirming that the deployment succeeded is left as an exercise (Section 5.3.1).) Finally, although we’ll add in the occasional Git commit/deployment in this tutorial, ultimately these will be up to you, and now is a good time to practice making such decisions on your own (Box 5.1).

5.4 Start Stylin’

As discussed in Section 5.2, CSS is a way of defining how elements on an HTML page look and are positioned, with styling that flows (“cascades”) down from element to element based on factors like which declaration came first, whether an element is the child of a parent element that has styles applied to it, or the specificity of the declaration.

So what do “parent”, “children”, and “specificity” mean in the context of a web page and how it gets styled? The idea is that every element on the page is contained inside another element, which in turn can contain other elements—like Russian nesting dolls.

We can visualize the parent and child structure of the elements on a typical page using the diagram in Figure 5.8.

The hierarchical tag structure shown in Figure 5.8 is known as the Document Object Model, or DOM for short.¹⁰ Each new level in the DOM is a child of the level above it. In other words, the html tag is the parent of the entire page, the body tag is a child of the html tag, and so on. The body tag then has its own children, which are the h1 and h2 elements, the unordered list ul, and the div elements. In CSS, styling rules flow down from parents to children unless another style interrupts and takes priority.

10. “DOM” is usually pronounced as a word, so “DOM” rhymes with “Mom”.

Our first application of these ideas will be to the repetitive inline styles that exist in our current example page. Now that you know about the DRY principle (Box 5.2), all that redundant styling should be causing a mild case of programmer’s itch, and the only cure is to eliminate the duplication.

If you are reading this after recently finishing Section 4.7, this sort of refactoring should be familiar, though this time through we are going to go a little more into details that weren’t covered before. If literally none of this is familiar, please refer back to Section 4.7.1 and then come back.

Let’s first look at cleaning up the div elements that share identical inline border styling, as seen in Listing 5.6.

Listing 5.6: Repeated inline styles violate the DRY principle.
index.html

Click here to view code image

<div style="border: 1px solid black;">
<div style="border: 1px solid black;">
<div style="border: 1px solid black;">

To make the example code cleaner, we are going to use the style block that has already been added to our new initial HTML in Listing 5.4 (the best practice is actually to put the CSS rules in a separate file, a task we’ll undertake in Section 9.6).

Now let’s get rid of the repetition in Listing 5.6 by adding in our first CSS declaration, as shown in Listing 5.7.¹¹

11. For simplicity, partial code listings like Listing 5.7 won’t necessarily show the full indentation level, but (as discussed in Box 1.4) you should strive to use the proper indentation level in order to keep your markup tidy.

Listing 5.7: Adding our first CSS style.
index.html

Click here to view code image

  <style>
    div {
      border: 1px solid black;
    }
  </style>

Figure 5.9 shows the anatomy of the CSS rule from Listing 5.7: the div part of the statement, which is outside the curly braces, is called the CSS selector (in this case targeting only div HTML elements). Then there is a declaration made up of a property (border) and a value (1px solid black) separated from the property by a colon. Finally, there is a semicolon at the end of the line that ends the style. (Just a warning: a lot of these terms get mixed up in regular usage. For example, people will sometimes refer to the whole thing, including the selector, as the declaration.)

Although the spacing shown in Listing 5.7 is typical, CSS is similar to HTML in that whitespace is ignored by the browser. For the sake of any humans viewing your markup, though, it’s a good idea to follow certain formatting conventions (Box 5.4).

After adding the CSS in Listing 5.7, delete all the style=”border: 1px solid black;” attributes from the four div tags (Listing 5.8).

Listing 5.8: How the entire page should now look.
index.html

Click here to view code image

    <h2>I'm an h2</h2>
    <div>
      <a href="https://example.com/" style="color: green;">I'm a link</a>
    </div>
    <div>
      <a href="https://example.com/" style="color: green;">I'm a link</a>
    </div>
    <div>
      <a href="https://example.com/" style="color: green;">I'm a link</a>
    </div>
    <div>
      <a href="https://example.com/" style="color: green;">I'm a link</a>
    </div>
  </body>
</html>

Save the changes, refresh the page in your browser… and BAM! Everything should look the same. (If not, double-check your work to see if you can get your results to match.)

So what happened here? The declaration that we added in Listing 5.7 is a CSS statement that tells the browser it needs to apply a 1-pixel wide solid black border to all of the divs in the body of the html. (We’ll learn more about pixels in Section 7.3.) The result is a simplification of the code without any change in the page’s appearance.

Now that we’ve seen how to consolidate a bunch of inline styles into a single CSS declaration, let’s do the same thing for the links that are colored red via inline styles inside the lis. First add the new style, as shown in Listing 5.9.

Listing 5.9: Add the new CSS.
index.html

<style>
  a {
    color: red;
  }

And then remove the inline styles from the links:

Click here to view code image

<li>
 <a href="https://example.com/">Link</a>
</li>
<li>
 <a href="https://example.com/">Link</a>
</li>
<li>
 <a href="https://example.com/">Link</a>
</li>

As before, the appearance shouldn’t change after refreshing the browser.

At this point, we’ve definitely made progress in the fight against inline style redundancy, but what about those links that are colored green at the bottom using inline styling? One way to clean up the inline styles would be to use CSS classes, which we’ll start covering in Section 5.5, but for now let’s see if we can do it with just generic CSS selectors.

Because the links in question are contained inside divs, and the other links on the page are not, we can use the nesting inheritance of CSS to define a style that changes only the color of links inside divs. We can accomplish this by adding a declaration to the style block, and then removing the inline styles from the links on the page. Your entire test page should now look like Listing 5.10.

Listing 5.10: Whole page with new styling to target links inside divs.
index.html

Click here to view code image

<!DOCTYPE html>
<html>
  <head>
    <title>Test Page: Don't Panic</title>
    <meta charset="utf-8">
    <style>
      a {
        color: red;
      }
      div {
        border: 1px solid black;
      }
      div a {
        color: green;
      }
    </style>
  </head>
  <body>
    <h1>I'm an h1</h1>
    <ul>
      <li>
        <a href="https://example.com/">Link</a>
      </li>
      <li>
        <a href="https://example.com/">Link</a>
      </li>
      <li>
        <a href="https://example.com/">Link</a>
      </li>
    </ul>
    <h2>I'm an h2</h2>
    <div>
      <a href="https://example.com/">I'm a link</a>
    </div>
    <div>
      <a href="https://example.com/">I'm a link</a>
    </div>
    <div>
      <a href="https://example.com/">I'm a link</a>
    </div>
    <div>
      <a href="https://example.com/">I'm a link</a>
    </div>
  </body>
</html>

The page is a lot cleaner now, isn’t it? Separating the styling from the content makes the page’s code much easier to read, but maybe you can already see the problem with the way that we’ve targeted the styles…

The problem is: if we were to add new divs anywhere on the page, and they happened to have links inside them, those links would be green even if that isn’t what we want. The reason why is that the selector we used in that declaration is way too generic. In Section 5.5, we’ll take a look at how to add styling with far greater specificity using CSS ids and classes.

5.5 CSS Selectors

Between Part I and the beginning of Part II, we have so far used only rudimentary targeting techniques for styles. In Part I, we learned how to add styles directly to elements, but this approach is brittle and inefficient. In this tutorial, so far we’ve used CSS that is separated from the content, but we have used only generic selectors like div or a. The problem with generic element selectors is that they apply to all the elements on the page. So, how can we apply styling to specific elements rather than to every single one?

There are two methods, one that targets only one element per page—the id (or “identification”) selector¹²—and one able to target multiple elements—the class selector. Let’s edit our example HTML to add this kind of targeting to our page.

12. The traditional contraction for “identification” is the uppercase “ID”, but in computer contexts the lowercase “id” has become a common alternative (despite the possible confusion with the psychoanalytic word id). This is due in large part to the convention of using lowercase tags (e.g., div instead of DIV) in modern HTML markup.

Ids and classes are always applied only to the opening tag of an element, and they always have the same format. We’ll use the div tag for concreteness: