Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

8 Tables and Other Structured Data Elements

The main goal of HTML is to structure, define, and describe content. At this point you’ve seen most types of data: paragraphs and headings, images and other media, links, and layout elements. But there’s a whole world of data out there that enhances websites by being described properly.

In this chapter, you’ll learn about some of the more advanced types of structured data, like tables and definition lists. You’ll also learn about schemas, a way for you to describe your own data.

Tables

Tables have been used on webpages as long as there have been webpages. They are used to display “tabular” data, which is data that is presented in rows and columns (FIGURE 8.1).

A figure depicts a table in HTML. The column headers are Team and Location. The Team and Location mentioned in the table are as follows: Yankees - Bronx, NY; Red Sox - Boston, MA; Dodgers - Los Angeles, CA; Phillies - Philadelphia, PA. — Figure 8.1 A basic table in HTML

Table markup

Several elements go into making a table:

<table>: This is the parent element. All the data in the table will be wrapped in the opening and closing table tags.
<caption>: Specifies a title or caption for the table. If included, this should be the first child element of the table.
<thead>: This stands for “table header” and will contain the column headings.
<tbody>: Stands for “table body” and contains the primary content (or data) of the table.
<tr>: Short for “table row.” Each row of data goes in between opening and close tr tags.
<td>: This is a cell of data (td stands for “table data”).
<th>: If contained inside <thead>, th (table heading) can replace td as the table cell. Data tagged with <th> will usually appear in bold by default.
<tfoot>: The “table footer,” this contains the table’s footer (example in FIGURE 8.2).

A table in HTML is shown, with the sum of values in a column. — Figure 8.2 This table shows the sum of the values in each column at its bottom, so using `<tfoot>` for the totals is appropriate.

A figure shows a table that displays the total of the values in a column at the bottom. The column headers are Team and Home Runs. The Team and Home Run mentioned in the table are as follows: Yankees - 306, Red Sox - 245, Dodgers - 279, and Phillies - 215. The total is displayed as 1,045 in the last row.

CODE 8.1 The HTML markup behind the baseball table shown in FIGURE 8.3

Click here to view code image

<table border="1">
    <caption>Baseball players with their
    → teams and numbers.</caption>
    <thead>
        <tr>
           <th>Player</th>
           <th>Team</th>
           <th>Number</th>
        </tr>
    </thead>
    <tbody>
        <tr>
           <td>Derek Jeter</td>
           <td>Yankees</td>
           <td>2</td>
        </tr>
        <tr>
           <td>David Ortiz</td>
           <td>Red Sox</td>
           <td>34</td>
        </tr>
        <tr>
           <td>Roy Halladay</td>
           <td>Phillies</td>
           <td>34</td>
        </tr>
        <tr>
           <td>Mike Piazza</td>
           <td>Mets</td>
           <td>31</td>
        </tr>
    </tbody>
</table>

A baseball player table created using HTML code is shown. — Figure 8.3 A table of baseball players, their teams, and their numbers

The table captioned "Baseball players with their teams and numbers" is shown. The column headers are player, Team, and number. The row-wise data mentioned in the table are as follows: ( Derek Jeter, Yankees, 2); ( David Ortiz, Red Sox, 34); ( Roy Halladay, Phillies, 34); ( Mike Piazza, Mets, 31).

Sample table markup

CODE 8.1 shows the markup for a simple table that lists baseball players, the teams they were on when they retired, and their uniform numbers.

A quick note on this code: the border attribute is actually deprecated in HTML5. You should use CSS to define borders. It’s used here only so you can see the different cells in the table.

Let’s take it one section at a time, beginning with the header. Adding this header will make three columns with bold text, denoting column headings (FIGURE 8.4).

A figure depicts the column headers of the baseball players' table. The headers are Player, Team, and Number, displayed in bold characters within three consecutive cells of a table. — Figure 8.4 The header for the baseball players table as it will appear when rendered in a browser

A table header and a table row will look very similar in markup, but both should be included. We’ll walk through both so you can see how a table is built. The main difference is that th cells will appear in bold.

To create the table header:

Type <table border="1">.

The border attribute here would normally be excluded in favor of adding it via CSS, but it will make reading the table much easier for the purposes of this example. The 1 means “1 pixel” and it will create a border around the entire table and around each cell and header.
Type <thead> to begin the header.
Type <tr> to start the row within the header.
Type <th>Player</th> to enter the first of the three column heads.
Type <th>Team</th>.
Type <th>Number</th>.
Type </tr> to close off the row of column heads.
Type </thead> to mark the end of the header.

To create a table row:

Type <tbody>.
Type <tr>.
Type <td>Derek Jeter</td>.
Type <td>Yankees</td>.
Type <td>2</td>.
Type </tbody>.
Type </table>.

CODE 8.2 The full code for the table, with important areas highlighted

Click here to view code image

<table border="1">
    <thead>
        <th colspan="4">Aaron Judge</th>
        <th>RF</th>
    </thead>
    <tbody>
        <tr role="header">
            <td>Year</td>
            <td>Team</td>
            <td>BA</td>
            <td>HR</td>
            <td>RBI</td>
        </tr>
        <tr>
            <td>2017</td>
            <td rowspan="3">NYY</td>
            <td>.284</td>
            <td>52</td>
            <td>114</td>
        </tr>
        <tr>
            <td>2018</td>
            <td>.278</td>
            <td>27</td>
            <td>67</td>
        </tr>
        <tr>
            <td>2019</td>
            <td>.272</td>
            <td>27</td>
            <td>55</td>
        </tr>
        <tfoot>
            <tr>
               <td colspan="2">Totals:</td>
               <td>.278</td>
               <td>106</td>
               <td>236</td>
            </tr>
    </tfoot>
</table>

Extending rows and columns

You aren’t limited to strictly structured rows and columns. Thanks to the attributes colspan and rowspan, which accept a numeric value for the number of cells the column or row should span (or take up), you can tell the table “this cell should take up two columns” or “this cell should take up three rows”:

<th colspan="2">
<th rowspan="3">

These attributes come in handy when you want to build a more complicated table—one that mimics a baseball card, for example (FIGURE 8.5 and CODE 8.2).

A table with spanned columns and merged cells is shown. — Figure 8.5 A complex, baseball card–like table for Aaron Judge (batting average, home runs, and runs batted in). However, the table header has the player’s name spanning four columns. The Totals cell in the footer spans two columns. And since he’s played for the same team for his entire career, the first Team entry takes up three rows.

A figure presents a table for Aaron Judge that displays batting average (BA), home runs (HR), and runs batted in (RBI). The table header that reads Aaron Judge spans 4 columns and the other header reads RF. The five column headers are as follows: year, team, BA, HR, and RBI. The years listed are 2017, 2018, and 2019 one below the other. The team mentioned is NYY corresponding to all the three years, and these three cells are merged. The row-wise data in the order of BA, HR, and RBI are as follows: 2017 - 0.284, 52, and 114; 2018 - 0.278, 27, and 67; 2019 - 0.272, 27, and 55; Totals - 0.278, 106, and 236.

Doing this takes a little bit of math to get right, but it can make your tables look better and help you align data just the way you want to.

Miscalculating the rowspan can make a trainwreck of your table (FIGURE 8.6). Since the table is expecting another cell to fill the 2019 row, the cells no longer line up and there’s a random blank space.

A table with row span short by one row. — Figure 8.6 What happens when a `rowspan` is short by one row

A figure presents a table for Aaron Judge that displays batting average, home runs, and runs batted in. The table has 5 columns and 6 rows. The table header that reads Aaron Judge spans 4 columns and the other header reads RF. The five-column headers read as follows: year, team, BA, HR, and RBI. The years listed are as follows: 2017, 2018, and 2019 one below the other. The team mentioned is NYY. But the row span is 2 rows. So the BA value corresponding to the year 2019 is shifted one cell left. The HR and the RBI values also shift one cell left. So, the BA value 0.272 comes under the column header Team for the year 2019 and the last cell in that row is vacant. The row-wise data in the order of BA, HR, and RBI are as follows: 2017 - 0.284, 52, and 114; 2018 - 0.278, 27, and 67; 2019 - 27, 55, and blank space; Totals - 0.278, 106, and 236.

Similar problems arise when a column spans one too many cells (FIGURE 8.7). In this instance, the browser creates an entirely new column with a single cell to account for the overflow.

A table presents a table, with a new column for the overflow data. — Figure 8.7 What happens when a `colspan` spans one column too many

A figure presents a table for Aaron Judge that displays batting average, home runs, and runs batted in. The table has 6 columns and 6 rows. The table header that reads Aaron Judge spans 4 columns and the other header reads RF and it spans 1 column. The five column headers read as follows: year, team, BA, HR, and RBI. The years listed are as follows: 2017, 2018, and 2019. The team mentioned is NYY for all three years. The data inferred from the table in the order of above mentioned years are as follows: BA: 0.284, 0.278, and 0.272; HR: 52, 27, and 27; RBI: 114, 67, and 55. The total of each column is displayed in the last row corresponding to each column of BA, HR, and RBI. The row header "totals" is displayed in a merged cell with column span 3. So the total values are displaced one cell to the right. The total for BA, HR, and RBI are as follows: .278, 206, and 236. The total of BA is displayed in the HR column, the total of HR is displayed in the RBI column, and the total of RBI is displayed in the sixth vacant column at the right end of the table.

To add colspan to a table header:

Type <thead>.
Type <tr>.
Type <th but don’t add the closing >.
Type colspan="4">.

Since the head has two columns but it’s a five-column table, this colspan should be 4—one for the cell and three for the cells that are skipped.
Type Aaron Judge.
Type <th>RF</th>.
Type </tr>.
Type </thead>.

The result is the heading you see in Figure 8.5.

A figure presents the glossary of baseball terms. — Figure 8.8 A description list of baseball terms and their definitions

A figure depicts the description list of the baseball terms. The term batting average is aligned to the left side of the page. The description "The total number of hits divided by the number of at-bats" for this is given in the next line, and it is aligned to the center. In the next line, the term Home Run is displayed. The description "A fair hit that allows the batter to round all of the bases and cross home" is written below it. The third term Runs Batted In is displayed and the description "Any run credited to a specific batter that results from a fair hit ball or base on balls" is displayed below it. The second and third cases follow the same pattern as the first.

Description Lists

A description list is a fantastic example of structured, defined data. It’s an element that contains a list of terms and descriptions (or definitions) for those terms. A glossary is a perfect example (FIGURE 8.8).

The markup for a description list includes three tags:

<dl>: This is the container for the entire list. dl stands for “description list.”
<dt>: The dt (description term) is the term being described.
<dd>: This is the “description details.” It’s the text that describes the term.

CODE 8.3 shows you the code for the description list in Figure 8.8.

Description lists aren’t limited to definition/term lists. You can also use them for recipes, upcoming events, or dialogue (like in a script).

Semantically, a <dd> will be associated with the preceding <dt>. That means that you can have multiple <dd> elements following a single <dt>, and vice versa. If you have two <dt>s in a row, the very next <dd> will be associated with both of them.

To create an events list using a description list:

Type <dl> to start the list.
Type <dt>Opening Day</dt> to enter the first term to be described.
Type <dd>April 1, 2021</dd> to enter the description for the term you just added.
Type <dt>All-Star Game</dt> to add a new term to the list.
Type <dd>July 13, 2021</dd>.
Type <dd>Game held at Truist Park, home of the Atlanta Braves</dd> to add a second line of information about the term.
Type <dt>Postseason</dt>.
Type <dd>October 2021</dd>.
Type <dd>Rounds: Wild Card, Division Series, League Championship, World Series</dd>.
Type <dd> The winners in each league will play in the World Series. </dd>.
Type </dl> to close the description list.

The resulting list is shown in FIGURE 8.9.

A figure presents the description list of events, that includes the date, location and, other details for each event. — Figure 8.9 A description list of upcoming events in Major League Baseball

A figure depicts the description list of the upcoming events in Major League Baseball. The upcoming events mentioned are as follows: Opening day, All-Star Game, and Postseason. The details of each event are described below each event. The events are aligned to the left and the descriptions are aligned to the center. For the Opening day event, the date April 1, 2021, is displayed below it. For All-Star Game, the date July 13, 2021, and the location details are displayed one below the other. For Postseason, the event date October 2021 is displayed first. The details of the rounds are displayed below the date. The information regarding the winner is displayed on the last line.

This example shows that, by default, every <dd> is indented under the most recent <dt>, creating a nice visual hierarchy of terms and descriptions.

On Indenting Your Code

HTML does not require that code use any particular style of indentation. I add indents manually in my code. Some HTML editing software will add them for you.

Through the book, you’ll notice the use of indentation for each child element, like so:

<parent>
    <child>
         <grandchild>

This makes the code easier to follow, and you can quickly locate opening and closing tags.

Why Is Structured Data Important?

You might be wondering why we need to use specific structures for different kinds of data. After all, we could easily use an unordered list for description lists.

But using the right tags to define data is important for browsers, users, and search engines. A great example of defining data in HTML is the <address> tag:

<address>
    Yankee Stadium<br/>
    1 E 161 St.<br/>
    The Bronx, NY 10451
</address>

… which renders as FIGURE 8.10.

A figure shows an address displayed in three lines using the address tag. The address reads as follows: Yankee Stadium, 1 E 161 St., The Bronx, NY 10451. The italic font is used. — Figure 8.10 The <address> tag in action

Aside from it being italicized, there’s not much visually different about an address. You could easily use a <p> or <div>. But the <address> tag tells the browser and search engines, “This is the contact information for this page.” Even better, if the <address> tag is nested in an <article> tag, it indicates contact information specifically for that article.

What this ultimately leads to is better, more informative search results for users. Here’s what happens if you search online for “Yankee Stadium address” (FIGURE 8.11).

A screenshot presents a Google search results web page. — Figure 8.11 The answer shows up directly on the search results page.

A screenshot displays a Google search results page. The search text field displays the text Yankee stadium address. The Yankee Stadium address is displayed below that. The images of the Yankee Stadium is present on the right side of the web page. Also, the page displays some questions asked by people related to Yankee Stadium.

Without semantic meaning applied to the text (in this case, as an <address> tag), Google would have a much harder time knowing which data on the page contained the correct answer.

Using Schema.org vocabulary for custom structured data

This is a bit beyond the scope of “basic HTML and CSS,” but it’s important to know in the context of this conversation.

There are a number of different ways of annotating your structured content. By annotating your data, you help search engines better understand your page content and enable them to display your site with interesting search appearance elements. While there are several types of specifications, Schema.org is the commonly used type we’ll use in this book. These sets of markup are called schemas. Driven primarily by Schema.org, these schemas provide a vocabulary that search engines can potentially use to better understand what you’re presenting.

Common examples of schemas drive search engine results that you regularly see: information on movies and TV shows, recipes, and so on (FIGURES 8.12 and 8.13).

The Google search results page of the movie Field of Dreams. — Figure 8.12 Google uses movie schema from several different sites (IMDB, Wikipedia, and YouTube, to name a few) to build a special display for movies to show up in searches.

A screenshot displays a Google search results page of the movie Field of Dreams. The search text field displays the text field of dreams. The page displays links with information about the movie Field of Dreams from different sites like Wikipedia and YouTube. Several images and details of the movie are displayed on the right side of the web page.

A screenshot displays a Google search results page of the hot dog recipes. The search text field displays the text hot dog recipes. The links to recipes of hot dogs are displayed in card format on the page along with the thumbnail and rating for the link. — Figure 8.13 Recipes show up in a card format on Google, allowing users to see what looks best to them and then click through to the recipe.

If you wanted to, you could create a more meaningful event list. The main driver is an attribute called itemscope, which states that the element is about a specific item. Then we’d use the attribute itemtype to get the right schema from Schema.org to go with it. We can add more information to an element with itemprop, which allows you to set item properties based on the type of data represented (e.g., events will have a date; recipes will not).

To create an event with Schema.org vocabulary:

This task uses the following markup for an event that, alas, never took place:

Click here to view code image

  <dt>Field of Dreams Game</dt>
  <dd>August 13, 2020</dd>
  <dd>Game held in Dyersville,
  →Iowa</dd>
  <dd>Yankees vs. White Sox</dd>

After <dt, type itemscope.
Type itemtype={"https://schema.org/SportsEvent">.
After the first <dd tag (the one containing the date), type itemprop="startDate" content="2020-08-13T19:00">.

This is a machine-readable version of the date and time.
Replace Dyersville, Iowa with <span itemprop="location">Dyersville, Iowa</span>.
Replace Yankees with <span itemprop="awayTeam">Yankees</span>.
Replace White Sox with <span itemprop="homeTeam">White Sox </span>.

The resulting markup is shown in CODE 8.4.

While this doesn’t affect the display of your webpage, it gives search engines much more valuable information. You can imagine someone searching “Who is the home team for the Field of Dreams game?” Now search engines can find the answer in our tiny database.

Wrapping Up

You covered a lot of ground in this chapter, learning about important structures like tables and description lists. You also have a better understanding of structured data and its importance in creating a better, more user-friendly web.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for 8. Tables and Other Structured Data Elements

Create new playlist

Sign In

Sign Up

8

Tables and Other Structured Data Elements

Tables

Table markup

Sample table markup

Extending rows and columns

Description Lists

Why Is Structured Data Important?

Using Schema.org vocabulary for custom structured data

Wrapping Up

Table of Contents for
8. Tables and Other Structured Data Elements