Part I. Getting Started

I

Getting Started

1. Getting Started in Web Design

1

Getting Started in Web Design

The web has been around for more than 25 years now, experiencing euphoric early expansion, an economic-driven bust, an innovation-driven rebirth, and constant evolution along the way. One thing is certain: the web as a communication and commercial medium is here to stay. Not only that, it has found its way onto devices such as smartphones, tablets, TVs, and more. There have never been more opportunities to put web design know-how to use.

Through my experience teaching web design courses and workshops, I’ve had the opportunity to meet people of all backgrounds who are interested in learning how to build web pages. Allow me to introduce you to just a few:

“I’ve been a print designer for 17 years, and now I am feeling pressure to provide web design services.”

“I’ve been a programmer for years, but I want shift my skills to web development because there are good job opportunities in my area.”

“I tinkered with web pages in high school and I think it might be something I’d like to do for a living.”

“I’ve made a few sites using themes in WordPress, but I’d like to expand my skills and create custom sites for small businesses.”

Whatever the motivation, the first question is always the same: “Where do I start?” It may seem like there is a mountain of stuff to learn, and it’s not easy to know where to jump in. But you have to start somewhere.

This chapter provides an overview of the profession before we leap into building sites. It begins with an introduction to the roles and responsibilities associated with creating websites, so you can consider which role is right for you. I will also give you a heads-up on the equipment and software you will be likely to use—in other words, the tools of the trade.

Where Do I Start?

Maybe you are reading this book as part of a full course on web design and development. Maybe you bought it to expand your current skill set on your own. Maybe you just picked it up out of curiosity. Whatever the case, this book is a good place to start learning what makes the web tick.

There are many levels of involvement in web design, from building a small site for yourself to making it a full-blown career. You may enjoy being a “full-stack” web developer or just specializing in one skill. There are a lot of ways you can go.

If you are interested in pursuing web design or production as a career, you’ll need to bring your skills up to a professional level. Employers may not require a web design degree, but they will expect to see working sample sites that demonstrate your skills and experience. These sites can be the result of class assignments, personal projects, or a site for a small business or organization. What’s important is that they look professional and have well-written, clean HTML; style sheets; and scripts behind the scenes.

If your involvement is at a smaller scale—say you just have a site or two you’d like to publish—you may find using a template on an online website service is a great head start (see the sidebar “I Just Want My Own Site”). Most allow you to tweak the underlying code, so what you learn in this book will help you customize the template to your liking.

It Takes a Village (Website Creation Roles)

When I look at a site, I see the multitude of decisions and areas of expertise that went into building it. Sites are more than just code and pictures. They often begin with a business plan or other defined mission. Before they launch, the content must be created and organized, research is performed, design from the broadest goals to finest details must happen, code gets written, and everything must be coordinated with what’s happening on the server to bring it to fruition.

Big, well-known sites are created by teams of dozens, hundreds, or even thousands of contributors. There are also sites that are created and maintained by a team with only a handful of members. It is also absolutely possible to create a respectable site with a team of only yourself. That’s the beauty of the web.

In this section, I’ll introduce you to the various disciplines that contribute to the creation of a site, including roles related to content, design, and code. You may end up specializing in just one area of expertise, working as part of a team of specialists. If you are designing sites on your own, you will need to wear many hats. Consider that the day-to-day upkeep of your household requires you to be part-time chef, housecleaner, accountant, diplomat, gardener, and construction worker—but to you it’s just the stuff you do around the house. As a solo designer, you’ll handle many web-related disciplines, but it will just feel like the stuff you do to make a website.

Content Wrangling

Anyone who uses the title “web designer” needs to be aware that everything we do supports the process of getting the content, message, or functionality to our users. Furthermore, good writing can help the user interfaces we create be more effective, from button labels to error messages.

Of course, someone needs to create all that content and maintain it—don’t underestimate the resources required to do this successfully. Good writers and editors are an important part of the team. In addition, I want to call your attention to two content-related specialists in modern web development: the Information Architect (IA) and the Content Strategist.

Information architecture

An Information Architect (also called an Information Designer) organizes the content logically and for ease of findability. They may be responsible for search functionality, site diagrams, and how the content and data are organized on the server. Information architecture is inevitably entwined with UX and UI design (defined shortly) as well as content management. If you like organizing or are gaga for taxonomies, information architecture may be the job for you. The definitive text for this field as it relates to the web is Information Architecture: For the Web and Beyond, by Louis Rosenfeld and Peter Morville (O’Reilly).

Content strategy

When the content isn’t right, the site can’t be fully effective. A Content Strategist makes sure that every bit of text on a site, from long explanatory text down to the labels on buttons, supports the brand identity and marketing goals of the organization. Content strategy may also extend to data modeling and content management on a large and ongoing scale, such as planning for content reuse and update schedules. Their responsibilities may also include how the organization’s voice is represented on social media. A good place to learn more is the book Content Strategy for the Web, 2nd Edition, by Kristina Halvorson and Melissa Rich (New Riders).

All Manner of Design

Ah, design! It sounds fairly straightforward, but even this simple requirement has been divided into a number of specializations when it comes to creating sites. Here are a few of the job descriptions related to designing a site, but bear in mind that the disciplines often overlap and that the person calling herself the “designer” often is responsible for more than one (if not all) of these responsibilities.

User Experience, Interaction, and User Interface design

Often, when we think of design, we think about how something looks. On the web, the first matter of business is designing how the site works. Before you pick colors and fonts, it is important to identify the site’s goals, how it will be used, and how visitors move through it. These tasks fall under the disciplines of User Experience (UX) design, Interaction Design (IxD), and User Interface (UI) design. There is a lot of overlap between these responsibilities, and it is not uncommon for one person or team to handle all three.

The User Experience designer takes a holistic view of the design process—ensuring the entire experience with the site is favorable. UX design is based on a solid understanding of users and their needs based on observations and interviews. According to Donald Norman (who coined the term), UX design includes “all aspects of the user’s interaction with the product: how it is perceived, learned, and used.” For a website or application, that includes the visual design, the user interface, the quality and message of the content, and even the overall site performance. The experience must be in line with the organization’s brand and business goals in order to be successful.

The goal of the Interaction Designer is to make the site as easy, efficient, and delightful to use as possible. Closely related to interaction design is User Interface design, which tends to be more narrowly focused on the functional organization of the page as well as the specific tools (buttons, links, menus, and so on) that users use to navigate content or accomplish tasks.

The following are deliverables that UX, UI, or interaction designers produce:

User research and testing reports

Understanding the needs, desires, and limitations of users is central to the success of the design of the site or web application. The approach of designing around the user’s needs is referred to as User-Centered Design (UCD), and it is central to contemporary web design. Site designs often begin with user research, including interviews and observations, in order to gain a better understanding of how the site can solve problems or how it will be used. It is typical for designers to do a round of user testing at each phase of the design process to ensure the usability of their designs. If users are having a hard time figuring out where to find content or how to move to the next step in a process, then it’s back to the drawing board.

Wireframe diagrams

A wireframe diagram shows the structure of a web page using only outlines for each content type and widget (Figure 1-1). The purpose of a wireframe diagram is to indicate how the screen real estate is divided and where functionality and content such as navigation, search boxes, form elements, and so on, are placed. Colors, fonts, and other visual identity elements are deliberately omitted so as not to distract from the structure of the page. These diagrams are usually annotated with instructions for how things should work so the development team knows what to build.

Site diagram

A site diagram indicates the structure of the site as a whole and how individual pages relate to one another. Figure 1-2 shows a very simple site diagram. Some site diagrams fill entire walls!

Storyboards and user flow charts

A storyboard traces the path through a site or application from the point of view of a typical user (a persona in UX lingo). It usually includes a script and “scenes” consisting of screen views or the user interacting with the screen. The storyboard aims to demonstrate the steps it takes to accomplish tasks, outlines possible options, and also introduces some standard page types. Figure 1-3 shows a simple storyboard. A user flow chart is another method for showing how the parts of a site or application are connected, but it tends to focus on technical details rather than telling a story. For example, “when the user does this, it triggers that function on the server.” It is common for designers to create a user flow chart for the steps in a process such as member registration or online payments.

There are many books on UX, interaction, and UI design, but these are a few of the classics to get you started:

• The Elements of User Experience: User-Centered Design for the Web and Beyond by Jesse James Garrett (New Riders)
• Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability by Steve Krug (New Riders)
• The Design of Everyday Things by Don Norman (Basic Books)
• About Face: The Essentials of Interaction Design, 4th Edition by Alan Cooper, Robert Reimann, David Cronin, and Christopher Noessel (Wiley)
• Designing Interfaces, 2nd Edition by Jenifer Tidwell (O’Reilly)
• 100 Things Every Designer Needs to Know about People by Susan Weinschenk (New Riders)
• Designing User Experience: A Guide to HCI, UX and Interaction Design by David Benyon (Pearson)

Visual (graphic) design

Because the web is a visual medium, web pages require attention to their visual presentation. First impressions are everything. A graphic designer creates the “look and feel” of the site—logos, graphics, type, colors, layout, and so on—to ensure that the site makes a good first impression and is consistent with the brand and message of the organization it represents.

There are many methods and deliverables that can be used to present a visual design to clients and stakeholders. The most traditional are sketches or mockups (created in Photoshop or a similar tool) of the way the site might look, such as the home page mockups shown in Figure 1-4.

Now that sites appear on screens of all sizes, many designers prefer to discuss the visual identity (colors, fonts, image style, etc.) in a way that isn’t tied to a specific layout like the typical desktop view shown in Figure 1-4. The idea is to agree upon a visual language for the site before production begins.

One option for separating style from screen size is to use style tiles, a technique introduced by Samantha Warren (see Note). Style tiles include examples of color schemes, branding elements, UI treatments, text treatment, and mood (Figure 1-5). Once the details are decided upon, they can be implemented into working prototypes and the final site. For more on this technique, visit Samantha’s excellent site, styletil.es, where you can download a template.

Graphic designers may also be responsible for producing the image assets for the site. They will need to know how to optimize images for the fastest delivery and how to address the requirements of varying screen sizes. It is also common for the development team to handle image optimization, but I think it is a skill every visual designer should have. We’ll discuss image optimization in Chapter 24, Image Asset Production.

Designers may also be responsible for creating a style guide that documents style choices, such as fonts, colors, and other style embellishments, in order to keep the site consistent over time. For a list of examples, articles, books, and podcasts about web style guides, visit the “Website Style Guide Resources” page at styleguides.io.

Code Slinging

A large share of the website building process involves creating and troubleshooting the documents, style sheets, scripts, and images that make up a site. At web design firms, the team that handles the creation of the files that make up the site (or templates for pages that get assembled dynamically) is usually called the development or production department.

Development falls under two broad categories: frontend development and backend development. Once again, these tasks may fall to specialists, but it is just as common for one person or team to handle both responsibilities.

Frontend development

Frontend refers to any aspect of the design process that appears in or relates directly to the browser. That includes HTML, CSS, and JavaScript, all of which you will need to have intricate knowledge of if you want a job as a web developer. Let’s take a quick look at each.

Authoring/markup (HTML)

Authoring is the process of preparing content for delivery on the web, or more specifically, marking up the content with HTML tags that describe its content and function.

HTML (HyperText Markup Language) is the authoring language used to create web page documents. The current version (and the version documented in this book) is HTML 5.2. Appendix D, From HTML+ to HTML5, tells the history of HTML and lists what makes HTML5 unique.

HTML is not a programming language; it is a markup language, which means it is a system for identifying and describing the various components of a document such as headings, paragraphs, and lists. The markup indicates the document’s underlying structure (you can think of it as a detailed, machine-readable outline). You don’t need programming skills—only patience and common sense—to write HTML.

The best way to learn HTML is to write out some pages by hand, as we will be doing in the exercises in Part II of this book.

Styling (CSS)

While HTML is used to describe the content in a web page, Cascading Style Sheets (CSS) describe how that content should look (see Note). The way the page looks is referred to as its presentation. Fonts, colors, background images, line spacing, page layout, and so on, are all controlled with CSS. You can even add special effects and basic animation to your page.

The CSS specification also provides methods for controlling how documents will be presented in contexts other than a browser, such as in print or read aloud by a screen reader; however, we won’t be covering them much here.

Although it is possible to publish web pages using HTML alone, you’ll probably want to take on style sheets so you’re not stuck with the browser’s default styles. If you’re looking into designing websites professionally, either as a designer or as a developer, proficiency at style sheets is mandatory.

JavaScript and DOM scripting

JavaScript is a scripting language that adds interactivity and behaviors to web pages, including these (to name just a few):

• Checking form entries for valid entries
• Swapping out styles for an element or an entire site
• Loading scrolling feeds with more content automatically
• Making the browser remember information about users
• Building interface widgets, such as embedded video players or special form inputs

You may also hear the term DOM scripting used in relation to JavaScript. DOM stands for Document Object Model, and it refers to the standardized list of web page elements that can be accessed and manipulated using JavaScript (or another scripting language).

Frontend developers may also be required to be familiar with JavaScript frameworks (such as React, Bootstrap, Angular, and others) that automate a lot of the production process. They’ll likely also need to be handy with AJAX (which stands for “Asynchronous JavaScript And XML”), a technique used to load content in the background, allowing the page to update smoothly without reloading (like those automatically refreshing feeds).

Web scripting definitely requires some traditional computer programming prowess. While many web developers have degrees in computer science, it is also common for developers to be self-taught. A few developers I know started by copying and adapting existing scripts, then gradually added to their programming skills with each new project. Still, if you have no experience with programming languages, the initial learning curve may be a bit steep.

If you want to be a web developer for a living, JavaScript is a basic requirement. Designers will benefit from understanding what JavaScript can do, but may not need to learn to write it if they are working with a development team. Chapter 21, Introduction to JavaScript, will get you started understanding how it works, and I recommend Learning JavaScript by Ethan Brown (O’Reilly) to learn more.

Backend development

Backend developers focus on the server, including the applications and databases that run on it. They may be responsible for installing and configuring the server software (we’ll be looking more at servers in Chapter 2, How the Web Works). They will certainly be required to know at least one, and probably more, server-side programming languages, such as PHP, Ruby, .NET (or ASP.NET), Python, or JSP, in order to create applications that provide the functionality required by the site. Applications handle tasks and features like forms processing, content management systems (CMSs), and online shopping, just to name a few.

Additionally, backend developers need to be familiar with configuring and maintaining databases that store all of the data for a site, such as the content that gets poured into templates, user accounts, product inventories, and more. Some common database languages include MySQL, Oracle, and SQL Server.

Backend development is well beyond the scope of this book, but it is important to know the sorts of tasks that get taken care of at the server level. You should be aware that it is possible to get functionality like shopping carts, mailing lists, and so on as prepackaged solutions from your hosting company without having to program it from scratch.

Other Roles

Not surprisingly, there are a myriad of other roles that contribute to the creation and maintenance of a site. Here are a few common roles that fall just outside the moniker “web design.”

Product manager

The product manager of a website or application guides its design and development in a way that meets business goals. This member of the team must have a thorough understanding of the target market as well as the processes involved in the creation of the site itself. Product managers develop the overall strategy for the site from a marketing perspective, including how and when it gets released.

Project manager

The project manager coordinates the designers, developers, and everyone else who is working on the site. They manage things like timelines, development approaches, deliverables, and so on. The project manager works with the product manager and other product owners to make sure that the project gets done on time and on budget.

SEO specialist

A website or application isn’t much good if nobody knows it exists, so it is crucial that a site be easily found by search engines. Search Engine Optimization (SEO) is a discipline focused on tweaking the site structure and code in a way that increases the chances it will be highly ranked in search results. There may be an SEO specialist on the in-house team, or a company may choose to hire an outside SEO firm. SEO is sometimes perceived as a dark art, but there are many ways to improve findability that are not underhanded. In fact, the number one technique for improving SEO is simply having good content with savvy HTML markup.

Multimedia producers

One of the cool things about the web is that you can add multimedia elements to a site, including sound, video, animation, and even interactive games. Creating multimedia elements is generally best left to artists and technicians in those fields, although they may be part of the web team if video, animation, or interactivity are core to the site’s mission.

That concludes our stroll through the virtual village of workers involved in the creation of a website. The larger the site, the more likely each team member will have a narrow specialization and job titles like “UX Lead for Error Messages.” More likely, everybody on the team will possess a spectrum of skills, and the lines between disciplines will blur. For example, I do Interaction and User Interface design, graphic design, HTML, and CSS, but I do not write JavaScript, work on the server, or get involved with content organization. In this book, I aim to give you a foundation in the frontend technologies that will prepare you for a number of roles.

Gearing Up for Web Design

It should come as no surprise that professional web designers require a fair amount of gear, both hardware and software. One question I’m frequently asked is, “What do I need to buy?” I can’t tell you specifically what to buy, but I will provide an overview of the typical tools of the trade.

Equipment

For a comfortable web development environment, I recommend the following equipment:

A solid, up-to-date computer

Macintosh, Windows, or Linux is fine, so use whatever you have and are comfortable with. Creative departments in professional web development companies tend to be Mac-based. For backend work, Linux and Windows are popular. Although it is nice to have a super-fast machine, the files that make up web pages are very small and tend not to be too taxing on computers. Unless you’re getting into sound and video editing, don’t worry if your current setup is not the very latest and greatest.

A large monitor

Although not a requirement, a large monitor makes life easier. The more monitor real estate you have, the more windows and control panels you can have open at the same time. You can also see more of your page to make design decisions. If you’re using a large monitor, just make sure you design for users with smaller monitors and devices in mind.

A second computer for testing

Many designers and developers find it useful to have a test computer running a different platform than the computer they use for development (i.e., if you design on a Mac, test on a PC). Because browsers work differently on Macs than on Windows machines, it’s critical to test your pages in as many environments as possible, and particularly on the current Windows operating system. If you are a hobbyist web designer working at home, you could check your pages on a friend’s machine. Mac users should check out the “Run Windows on Your Mac” sidebar.

Mobile devices for testing

The web has gone mobile! That means it is absolutely critical that you test the appearance and performance of your site on browsers on smartphones and tablet devices. Device testing is discussed in Chapter 17, Responsive Web Design.

A scanner and/or camera

If you anticipate making your own images and textures, you’ll need some tools for creating them.

Web Production Software

There’s no shortage of software available for creating web pages. In the early days, we just made do with tools originally designed for print. Today, there are wonderful tools created specifically with web design in mind that make the process more efficient. It is a delicate business listing software in a book such as this because a) there are so many programs, b) everyone has their personal favorite, and c) new tools come along so rapidly that there are surely newer, cooler options that you have access to that didn’t exist as I wrote this.

That said, here is a general overview of the types of software that comprise the tools of our trade, along with a few specific mentions of the most popular in each class.

Coding tools

Although you can get by with the simple text editors that come with your computer, a dedicated code editor makes the task of writing HTML, CSS, and JavaScript much easier. Code editors understand the syntax of the code you write, so they can do things for you like color coding, error detection, and automatically finishing simple tasks like closing HTML tags. Some provide page previews so you can view the results of your code as you work.

Figure 1-6 shows how an HTML document looks in the Sublime Text editor. Here are just a few of the better-known code editors for web production that are worth exploring:

• Sublime Text (sublimetext.com)
• Atom (free from GitHub; atom.io)
• Brackets (free from Adobe; brackets.io)
• CodeKit (codekitapp.com; Mac only)
• Adobe Dreamweaver (www.adobe.com/products/dreamweaver.html)
• Coda (panic.com/coda/)
• Microsoft Visual Studio (visualstudio.com)

User interface and layout tools

There is a new breed of interface design tools made specifically for websites and other applications. Because they have been designed from scratch with interface design in mind, they seem to anticipate a web designer’s every need. Interface design tools make it easy to design multiple layouts (such as layouts at various screen sizes) as well as export images and code for use in production. Some allow basic interactivity such as clicks and swipes, so your mockups can be shared online and used for basic interface testing.

Sketch (sketchapp.com, Mac only), shown in Figure 1-7, is extremely popular at the time of this writing. Other options include the following:

• Affinity Designer (affinity.serif.com/en-us/designer/)
• Adobe XD (www.adobe.com/products/xd.html)
• Figma (figma.com)
• UXPin (uxpin.com)

Web graphic creation tools

It is certainly possible to create all of the images you need for a site by using one of the interface design tools just listed. There are also programs that focus solely on image creation that can export files in web-appropriate formats. For professional designers, the Adobe Creative Cloud (adobe.com) suite of tools, which includes Photoshop (Figure 1-8), Illustrator, and other high-end design tools, is worth the investment.

If the Adobe monthly subscription fee is out of reach, you can try lower-cost alternatives that provide many of the same features. The number of graphics tools out there is dizzying, so I’m gathering just a few here:

• GIMP (free, open source; gimp.org)
• Corel PaintShop Pro (for photo editing; paintshoppro.com; Windows only)
• Corel Draw (for vector drawing; coreldraw.com; Windows only)
• Pixelmator (pixelmator.com; Mac only)

The following image editors work right in your browser, without the need to download a program, although you do need to pay for an account:

• SumoPaint (sumopaint.com)
• Pixlr (pixlr.com)

A variety of browsers

One of the biggest challenges for web designers is that our sites may look and behave differently from browser to browser. For this reason, it is critical that we test our designs early and often on the widest range of browsers possible. These are the browsers designers and developers keep around for testing:

• Chrome (google.com/chrome)
• Firefox (www.mozilla.org)
• MS Edge (www.microsoft.com/en-us/windows/microsoft-edge; Windows only)
• Internet Explorer 9–11 (www.microsoft.com; search “Internet Explorer”; Windows only)
• Safari (support.apple.com/downloads/#safari; Mac only)
• Opera (opera.com)

You will also need to test on a variety of smartphone browsers including iOS Safari, Android browsers, and third-party mobile browsers. We will discuss mobile testing further in Chapter 17.

File management and transfer tools

Web design and development involves a lot of moving files around, particularly from the computer where you do your work to the server computer that hosts the site. To move files across the internet, you use an FTP (short for File Transfer Protocol) program. You will find that many hosting services offer their own FTP tools for uploading your files to their servers. Many of the code editors listed earlier also include built-in FTP functionality. Or, you can use a standalone FTP program, such as one of these:

• Filezilla (filezilla-project.org; free, all platforms)
• Cyberduck (cyberduck.io; Mac and Windows)
• WinSCP (winscp.net/eng/index.php; free, Windows only)
• Transmit (panic.com/transmit/; Mac only)

You may also find it useful to have a terminal application (command-line tool) that allows you to type Unix commands for setting file permissions, moving or copying files and directories, or managing the server software. Command-line tools, which have a number of uses in web design and development workflow, are discussed in more detail in Chapter 20, Modern Web Development Tools:

• Terminal (installed with macOS; shown in Figure 1-9)
• Cygwin (cygwin.com; Linux emulator for Windows that includes a command-line tool)

What You’ve Learned

I hope that this chapter has given you an overview of the many roles and responsibilities that fall under the umbrella of “web design.” I also hope that you come away realizing that you don’t need to learn everything. And even if you want to learn everything eventually, you don’t need to learn it all at once. So relax, and don’t worry. The other good news is that, while many professional tools exist, it is possible to create a basic website and get it up and running without spending much money by using freely available or inexpensive tools and your existing computer setup.

As you’ll soon see, it’s easy to get started making web pages—you will be able to create simple pages by the time you’re done reading this book. From there, you can continue adding to your bag of tricks and find your particular niche in web design. In the meantime, try answering the questions in Exercise 1-1.

Test Yourself

Each chapter in this book ends with a few questions that you can answer to see if you picked up the important bits of information. Answers appear in Appendix A.

1. Match these web professionals with the final product they might be responsible for producing:

   a.	Graphic designer	_____	HTML and CSS documents
   b.	Production department	_____	PHP scripts
   c.	User experience designer	_____	“Look and feel” deliverables
   d.	Backend programmer	_____	Storyboards

2. What does the W3C do?
3. Match the web technology with its appropriate task:

   a.	HTML	_____	Checks a form field for a valid entry
   b.	CSS	_____	Creates a custom server-side web application
   c.	JavaScript	_____	Identifies text as a second-level heading
   d.	Ruby	_____	Makes all second-level headings blue

4. What is the difference between frontend and backend web development?
5. What does an FTP tool do and how do you get one?

2. How the Web Works

2

How the Web Works

I got started in web design in early 1993—pretty close to the start of the web itself. That’s a quarter of a century ago (gasp!), but I still distinctly remember the first time I looked at a web page. It was difficult to tell where the information was coming from and how it all worked.

This chapter sorts out the pieces and introduces some basic terminology. We’ll start with the big picture and work down to specifics.

The Internet Versus the Web

No, it’s not a battle to the death, just an opportunity to point out the distinction between two words that are increasingly being used interchangeably.

The internet is an international network of connected computers. No company owns the internet; it is a cooperative effort governed by a system of standards and rules. The purpose of connecting computers together, of course, is to share information. There are many ways information can be passed between computers, including email (POP3/IMAP/SMTP), file transfer (FTP), secure shell (SSH), and many more specialized modes upon which the internet is built. These standardized methods for transferring data or documents over a network are known as protocols.

The web (originally called the World Wide Web, thus the “www” in site addresses) is just one of the ways information can be shared over the internet. It is unique in that it allows documents to be linked to one another via hypertext links—thus forming a huge “web” of connected information. The web uses a protocol called HTTP (HyperText Transfer Protocol). That acronym should look familiar because it is the first four letters of nearly all website addresses, as we’ll discuss in an upcoming section.

Serving Up Your Information

Let’s talk more about the computers that make up the internet. Because they “serve up” documents upon request, these computers are known as servers. More accurately, the server is the software (not the computer itself) that allows the computer to communicate with other computers; however, it is common to use the word “server” to refer to the computer as well. The role of server software is to wait for a request for information, and then retrieve and send that information back as quickly as possible.

There’s nothing special about the computers themselves…picture anything from a high-powered Unix machine to a humble personal computer. It’s the server software that makes it all happen. In order for a computer to be part of the web, it must be running special web server software that allows it to handle HyperText Transfer Protocol transactions. Web servers are also called HTTP servers.

There are many server software options out there, but the two most popular are Apache (open source software) and Microsoft Internet Information Services (IIS). Apache is freely available for Unix-based computers and comes installed on Macs running macOS. There is a Windows version as well. Microsoft IIS is part of Microsoft’s family of server solutions.

Every computer and device (router, smartphone, car, etc.) connected to the internet is assigned a unique numeric IP address (“IP” stands for “Internet Protocol”). For example, as I write this, the computer that hosts oreilly.com has the IP address 199.27.145.64. All those numbers can be dizzying, so fortunately, the Domain Name System (DNS) was developed to allow us to refer to that server by its domain name, “oreilly.com”, as well. The numeric IP address is useful for computer software, while the domain name is more accessible to humans. Matching the text domain names to their respective numeric IP addresses is the job of a separate DNS server. If you think of an IP address as a telephone number, the DNS server would be the phonebook.

It is possible to configure your web server so that more than one domain name is mapped to a single IP address, allowing several sites to share a single server.

A Word About Browsers

We now know that the server does the servin’, but what about the other half of the equation? The software that does the requesting is called the client. People use desktop browsers, mobile browsers, and other assistive technologies (such as screen readers) as clients to access documents on the web. The server returns the documents for the browser (also referred to as the user agent in technical circles) to display.

The requests and responses are handled via the HTTP protocol, mentioned earlier. Although we’ve been talking about “documents,” HTTP can be used to transfer images, movies, audio files, data, scripts, and all the other web resources that commonly make up websites and applications.

It is common to think of a browser as a window on a computer monitor with a web page displayed in it. These are known as graphical browsers or desktop browsers and for a long time, they were the only web-viewing game in town. The most popular desktop browsers as of this writing include Edge and Internet Explorer for Windows, Chrome, Firefox, and Safari, with Opera and Vivaldi bringing up the rear.

These days, however, more than half of web traffic comes from mobile browsers on smartphones and tablets such as Safari on iOS, Android and Chrome browsers on Android devices, Opera Mini, and a myriad of other default and installable mobile browsers (see en.wikipedia.org/wiki/Mobile_browser for a complete list). Navigating the web on a touch screen is the new normal.

It is also important to keep alternative web experiences in mind. Users with impaired sight may be listening to a web page read by a screen reader (or simply make their text extremely large). Users with limited mobility may use assistive technology such as joysticks or voice commands to access links and enter content. The sites we build must be accessible and usable for all users, regardless of their browsing experiences.

The web is also finding its way onto smart TVs and gaming systems, where users access our pages with TV remotes or Xbox controllers. You never know where the web will pop up next!

The reality is that pages may look and perform differently from browser to browser. This is due to varying support for web technologies, varying device capabilities, and the users’ ability to set their own browsing preferences. It is the most challenging aspect of designing and developing for our medium.

Web Page Addresses (URLs)

Every page and resource on the web has its own special address called a URL, which stands for Uniform Resource Locator. It’s nearly impossible to get through a day without seeing a URL (pronounced “U-R-L,” not “erl”) plastered on the side of a bus, printed on a business card, or broadcast on a television commercial. Web addresses are fully integrated into modern vernacular.

Some URLs are short and sweet. Others may look like crazy strings of characters separated by dots (periods) and slashes, but each part has a specific purpose. Let’s pick one apart.

The Parts of a URL

A complete URL is generally made up of three components: the protocol, the site name, and the absolute path to the document or resource, as shown in Figure 2-1.

1 http://

The first thing the URL does is to define the protocol that will be used for that particular transaction. The letters “HTTP” let the server know to use HyperText Transfer Protocol, or get into “web mode.” You may also see a URL begin with https://, which I explain in the “HTTPS, The Secure Web Protocol” sidebar.

2 www.example.com

The next portion of the URL identifies the website by its domain name. In this example, the domain name is “example.com.” The “www.” part at the beginning is the particular hostname at that domain. The hostname “www” has become a convention, but is not a rule. In fact, sometimes the hostname may be omitted. There can be more than one website at a domain (called subdomains). For example, there might also be “development.example.com,” “clients.example.com,” and so on.

3 /2018/samples/first.html

This is the absolute path through directories on the server to the requested HTML document, first.html. The words separated by slashes are the directory names, starting with the root directory of the host (as indicated by the initial /). Because the internet originally comprised computers running the Unix operating system, our current way of doing things still follows Unix rules and conventions, hence the / separating directory names.

To sum it up, the URL in Figure 2-1 says it would like to use the HTTP protocol to connect to a web server on the internet called “www.example.com” and to request the document first.html, located in the samples directory, which is in the 2018 directory.

Simplified URLs

Obviously, not every URL you see is so lengthy. To get to O’Reilly’s site, you’d expect to type oreilly.com instead of http://www.oreilly.com/index.html. Here’s why that works.

Skipping the protocol

Because nearly all web pages use the HyperText Transfer Protocol, the http:// part is often just implied. This is the case when site names are advertised in print or on TV, as a way to keep the URL easy to remember.

Additionally, browsers are programmed to add http:// automatically as a convenience to save you some keystrokes. It may seem like you’re leaving it out, but it is being sent to the server behind the scenes.

When we begin using URLs to create hyperlinks in HTML documents in Chapter 6, Adding Links, you’ll learn that it is necessary to include the protocol when making a link to a web page on another server.

Pointing to default files

Many addresses do not include a filename, but simply point to a directory, like these:

http://www.oreilly.com http://www.jendesign.com/resume/

When a server receives a request for a directory name rather than a specific file, it looks in that directory for a default document, typically named index.html. So when someone types the previous URLs into his browser, what he’ll actually see is this:

http://www.oreilly.com/index.html http://www.jendesign.com/resume/index.html

The name of the default file (also referred to as the index file) may vary, and depends on how the server is configured. In these examples, it is named index.html, but some servers use the filename default.htm. If your site uses server-side programming to generate pages, the index file might be named index.php or Default.aspx. Just check with your server administrator or the tech support department at your hosting service to make sure you give your default file the proper name.

Another thing to notice is that in the first example, the original URL did not have a trailing slash to indicate it was a directory. If the slash is omitted, the server checks to see if the request is a file or a directory. If it is a directory, the server asks the browser to send the request again with a slash. In the end, the slash is included for directories, even if it isn’t included the first time it is entered (see Performance Tip).

The index file is also useful for security. Some servers (depending on their configuration) display the contents of the directory if the default file is not found. Figure 2-2 shows how the documents in the housepics directory are exposed as the result of a missing default file. One way to prevent people from snooping around in your files is to be sure there is an index file in every directory. Your server administrator may also add other protections to prevent your directories from displaying in the browser.

The Anatomy of a Web Page

We’re all familiar with what web pages look like in the browser window, but what’s happening “under the hood”?

At the top of Figure 2-3, you see a minimal web page as it appears in a graphical browser. Although you see it as one coherent page, it is actually assembled from four separate files: an HTML document (index.html), a style sheet (kitchen.css), and two graphics (foods.png and spoon.png). The HTML document is running the show.

HTML Documents

You may be as surprised as I was to learn that the graphically rich and interactive pages we see on the web are generated by simple, text-only documents. The text file behind the scenes is referred to as the source document.

Take a look at index.html, the source document for the Jen’s Kitchen web page. You can see that it contains the text content of the page plus special tags (indicated with angle brackets, < and >) that describe each element on the page.

Adding descriptive tags to a text document is known as “marking up” the document. Web pages use a markup language called HyperText Markup Language, or HTML for short, which was created especially for documents with hypertext links. HTML defines dozens of text elements that make up documents such as headings, paragraphs, emphasized text, and of course, links. There are also elements that add information about the document (such as its title), media such as images and videos, and widgets for form inputs, just to name a few.

You can view the source for any web page. Exercise 2-1 gives you some prompts and pointers.

The version of HTML we use today is HTML5. There have been several versions of HTML since its birth in 1989, and a few that are still in use today. There is a complete history of HTML, all its versions, and an overview of what makes HTML5 unique in Appendix D, From HTML+ to HTML5.

A Quick Introduction to HTML Markup

You’ll be learning the nitty-gritty of markup in Part II, so I don’t want to bog you down with too much detail right now, but there are a few things I’d like to point out about how HTML works and how browsers interpret it.

Read through the HTML document in Figure 2-3 and compare it to the browser results. It’s easy to see how the elements marked up with HTML tags in the source document correspond to what displays in the browser window.

First, you’ll notice that the text within brackets (for example, <body> and <strong>) does not display in the final page. The browser displays only what’s between the tags—the content of the element. The markup is hidden. The tag provides the name of the HTML element—usually an abbreviation such as “h1” for “heading level 1,” or “em” for “emphasized text.”

Second, you’ll see that most of the HTML tags appear in pairs surrounding the content of the element. In our HTML document, <h1> indicates that the following text should be a first-level heading; </h1> indicates the end of the heading. Some elements, called empty elements, do not have content. In our sample, the <hr> tag indicates an empty element that tells the browser to “insert a horizontal rule here” as a thematic divider.

Because I was unfamiliar with computer programming when I first began writing HTML, it helped me to think of the tags and text as “beads on a string” that the browser interprets one by one, in sequence. For example, when the browser encounters an open bracket (<), it assumes all of the following characters are part of the markup until it finds the closing bracket (>). Similarly, it assumes all of the content following an opening <h1> tag is a heading until it encounters the closing </h1> tag. This is the manner in which the browser parses the HTML document. Understanding the browser’s method can be helpful when troubleshooting a misbehaving HTML document.

Where Are the Pictures?

Obviously, there are no pictures in the HTML file itself, so how do they get there when you view the final page? You can see in Figure 2-3 that each image is a separate file. The images are placed in the flow of the text with the HTML image element (img), which tells the browser where to find the graphic (its URL). When the browser sees the img element, it makes another request to the server for the image file, and then places it in the content flow.

The browser also sends requests to the server for style sheets (like kitchen.css), JavaScript files (.js), and other embedded media like audio and videos. The browser software (or more specifically, its rendering engine) brings the separate pieces together into the final page.

The assembly of the page generally happens in an instant, so it appears as though the whole page loads all at once. Over slow connections or if the page includes huge graphics or media files, the assembly process may be more apparent as images lag behind the text. The page may even need to be redrawn as new images, fonts, and style sheets arrive (although you can construct your pages in such a way that prevents this from happening).

Adding a Little Style

I want to direct your attention to one last key ingredient of our minimal page. Near the top of the HTML document there is a link element that points to the style sheet document kitchen.css. That style sheet includes a few lines of instructions for how the page should look in the browser. These are style instructions written according to the rules of Cascading Style Sheets (CSS). CSS allows designers to add visual style instructions (known as the document’s presentation) to the marked-up text (the document’s structure, in web design terminology). In Part III, you’ll get to know the power of Cascading Style Sheets.

Figure 2-4 shows the Jen’s Kitchen page without (top) and with (bottom) the style instructions. Browsers come equipped with default styles for every HTML element they support, so if an HTML document lacks custom style instructions, the browser will use its own. That’s what you see in the screenshot on the top. Even just a few style rules can make big improvements to the appearance of a page.

Adding Behaviors with JavaScript

To make elements on the page do something, you use a scripting language called JavaScript (see Note). There are no scripts on the Jen’s Kitchen page because I thought it best to keep things simple this early in the book, but know that JavaScript is an essential ingredient in modern websites.

Whereas HTML provides the structure and the CSS style sheet alters how things look, JavaScript adds a behavior component that controls how things work. Scripts may be standalone files on the server (with the .js suffix) or be written out right in the document. They may be triggered to run immediately when the page loads or be triggered by something the user does, like click or hover on an element or enter something in a form field.

You’ll get a basic introduction to JavaScript in Part IV of this book.

Putting It All Together

1. To wrap up our introduction to how the web works, let’s trace a typical stream of events that occurs with every web page that appears on your screen (Figure 2-5). Request a web page by either typing its URL (for example, http://jenskitchensite.com) directly in the browser or by clicking a link on a page. The URL contains the information needed to target a specific document on a specific web server on the internet. In this case, it points to the default file (index.html) in the top directory.
2. Your browser sends an HTTP request to the server named in the URL and asks for the specific file. The request also includes information about what languages the user can read and what types of files the browser can accept. If the URL specifies a directory (not a file), it is the same as requesting the default file in that directory.
3. The server looks for the requested file and issues an HTTP response in the form of an HTTP header. The header includes information about the file, like the last modified date, the length of the file, and its Content-Type (for example, an .html file has the content type “text/html”).
   1. If the page cannot be found, the server returns an error message. The message typically says “404 Not Found,” although more hospitable error messages may be provided. Other error types are possible as well (see the sidebar “HTTP Status Codes”).

      HTTP Status Codes

      Servers issue status codes in response to browser requests. The full list of status codes is quite long (you can read about them all at en.wikipedia.org/wiki/List_of_HTTP_status_codes), but here are a few common responses:

      200 OK

      301 Moved Permanently

      302 Moved Temporarily

      404 Not Found

      410 Gone (no longer available)

      500 Internal Server Error

   2. If the document is found, the server retrieves the requested file and returns it to the browser. If the site is dynamic, the server assembles the page from stored data before returning it to the browser.
4. The browser parses the HTML document. If the page contains images (indicated by the HTML img element) or other external resources like scripts or style sheets, the browser contacts the server again to request each resource specified in the markup.
5. The browser inserts each image in the document flow where indicated by the img element, applies styles, and runs scripts. And voilà! The assembled web page is displayed for your viewing pleasure.

I should note that I’ve depicted a traditional and simplified scenario here to tell you how web pages are put together. These days, it is common for web pages to be generated from content management systems (CMSs) that keep content in databases and use templates to assemble the data into pages on the fly. In that case, in Step 3b, there is a more complicated process of assembling the file from various parts rather than just handing off an existing file.

Test Yourself

Let’s play a round of “Identify That Acronym!” The following are a few basic web terms mentioned in this chapter. Answers are in Appendix A.

3. Some Big Concepts You Need to Know

3

Some Big Concepts You Need to Know

As the web matures and the number of devices we access it from increases exponentially, our jobs as web designers and developers get significantly more complicated. Frankly, there’s a lot more going on out there than I can fit in this book. In the chapters that follow, I will focus on the basic building blocks of web design—HTML elements, CSS styles, a taste of JavaScript, and web image production—that will give you a solid foundation for the further development of your skills.

Before we get to the nuts and bolts, I want to introduce some Big Concepts that every web designer needs to know. We’ll look at ideas and concerns that inform our decisions and contribute to the contemporary web environment. I’ll be referring back to the terminology introduced here frequently.

The heart of the matter is that as web designers, we never know exactly how the pages we create will be viewed. We don’t know which of the dozens of browsers might be used, whether it is on a desktop computer or something more portable, how large the browser window will be, what fonts are installed, whether functionality such as JavaScript is enabled, how fast the internet connection is, whether the pages are being read by a screen reader, and so on. The Big Concepts in this chapter are primarily reactions to and methods for coping with the inescapable element of the Unknown in our medium. They include the following:

• The multitude of devices
• Web standards
• Progressive enhancement
• Responsive Web Design
• Accessibility
• Site performance

Because we’re just getting started, I will keep the descriptions brief and fairly non-technical. My goal is that you have a basic understanding of what I mean by terms like “progressive enhancement” when you encounter them in lessons later. Many excellent articles and books have been written on each of these topics and their related production techniques, and I’ll provide pointers to resources for further reading.

A Multitude of Devices

Until 2007, we could be relatively certain that our users were visiting our sites while sitting at their desks, looking at a large monitor, using a speedy internet connection. We had all more or less settled on 960 pixels as a good width for a web page based on the most common monitor size. Back then, our biggest concern was dealing with the dozen or so desktop browsers and jumping through a few extra hoops to support quirky old versions of Internet Explorer. And we thought we had it rough!

Although you could access web pages and web content on mobile phones prior to 2007, the introduction of the iPhone and Android smartphones as well as faster networks heralded a huge shift in how, when, and where we do our web surfing (particularly in the United States, which lagged behind Asia and the EU in mobile technology). Since then, we’ve seen the introduction of phones and tablets of all different dimensions, as well as web browsers on TVs, gaming systems, and other devices. And the diversity is only going to increase. I think mobile web design expert Brad Frost sums it up nicely in his illustrations in Figure 3-1.

The challenge of designing for all of these devices goes beyond addressing differing screen sizes. There is a world of difference between using a site over a broadband connection and over a slow cell network. Designers need to resist making assumptions about network speed and context based on the screen size. Just because it is a small screen doesn’t mean it’s a slow connection or that the person is in a hurry. It’s not uncommon to leisurely browse the web on a smartphone while sitting on the couch at home with a solid WiFi connection. And iPads with larger, high-resolution displays may be accessing the internet on pokey 3G connections. In other words, it’s complicated!

For a lot of sites today, more people access the web via their mobile devices than on a desktop computer. Already, a significant portion of Americans use their mobile phones as their only access to the internet. That means it is critical to get the design and functionality right. We’ve made huge strides in serving a pleasing experience to users with handheld devices, and the technology for targeting their needs continues to head in the right direction.

What I want you to learn here is that the way you see your design as you’re working on it on your nice desktop machine is not how it will be experienced by everyone. Some will see it much smaller. Some will see it load painfully slowly. Some may be looking at it on a TV across the room. All web design professionals should keep this fact in mind.

For Further Reading

• Mobile First by Luke Wroblewski (A Book Apart). Luke was way ahead of the curve in insisting that sites work well on mobile devices, and he shares his perspective in this little book, which is jam-packed with ideas.

  Mobile Web?

  You may hear people use the term “mobile web,” but the truth is (as Stephen Hay put it in a tweet in 2011; see Figure 3-2), there is no Mobile Web any more than there is a Desktop Web, or a Tablet Web, or so on. There is just The Web, and it can be accessed from all manner of devices. As of this writing, “mobile web” is used as sort of a catchall term to describe our efforts to adapt our desktop design skills to accommodate a much wider variety of use cases. And, as we are finding out, there is more than one way to crack that nut.

  

Sticking with the Standards

So how do we deal with this diversity? A good start is to follow the standards documented by the World Wide Web Consortium (W3C). Sticking with web standards is your primary tool for ensuring your site is consistent on all standards-compliant browsers (that’s approximately 99% of browsers in current use). It also helps make your content forward-compatible as web technologies and browser capabilities evolve. Another benefit is that you can tell your clients that you create “standards-compliant” sites, and they will like you more.

The notion of standards compliance may seem like a no-brainer, but it used to be that everyone, including the browser makers, played fast and loose with HTML and scripting. The price we paid was incompatible browser implementations and the need to create sites twice to make them work for everyone. I talk more about web standards throughout this book, so I won’t go into too much detail here. Suffice it to say that the web standards are your friends. Everything you learn in this book will start you off on the right foot.

For Further Reading

• The W3C site (w3.org/standards) is the primary resource for all web standards documents.
• The bible for standards compliance and how it makes good business sense is Designing with Web Standards, 3rd Edition, by Jeffrey Zeldman (New Riders). It’s getting on in years, but the fundamentals are still solid.

Progressive Enhancement

With a multitude of browsers comes a multitude of levels of support for the web standards. In fact, no browser has implemented all the standards 100%, and there are always new technologies that are slowly gaining steam. Furthermore, users can set their own browser preferences, so they may have a browser that supports JavaScript but have chosen to turn it off. The point here is that we are faced with a wide range of browser capabilities—from only basic HTML support to all the bells and whistles.

Progressive enhancement is one strategy for dealing with unknown browser capabilities (see Note). When designing with progressive enhancement, you start with a baseline experience that makes the content or core functionality available to even the most rudimentary browsers or assistive devices. From there, you layer on more advanced features for the browsers that can handle them. You might finish with some “nice to have” effects, like animation or wrapping text around images in interesting shapes, that enhance the experience for users with the most advanced browsers, but aren’t really critical to the brand or message.

Progressive enhancement is an approach that informs all aspects of page design and production, including HTML, CSS, and JavaScript:

Authoring strategy

When an HTML document is written in logical order and its elements are marked up in a meaningful way, it will be usable on the widest range of browsing environments, including the oldest browsers, future browsers, and mobile and assistive devices. It may not look exactly the same, but the important thing is that your content is available. It also ensures that search engines like Google will catalog the content correctly. A clean HTML document with its elements accurately and thoroughly described is the foundation for accessibility.

Styling strategy

You can create layers of experience simply by taking advantage of the way browsers parse style sheet rules. Without going into too much technical detail, you can write a style rule that makes an element background red, but also include a style that gives it a cool gradient (a blend from one color to another) for browsers that know how to render gradients. Or you can use a cutting-edge CSS selector to deliver certain styles only to cutting-edge browsers. The knowledge that browsers simply ignore properties and rules they don’t understand gives you license to innovate without bringing older browsers to their knees. You just have to be mindful of styling the baseline experience first, then adding improvements once the minimum requirements are met.

Scripting strategy

As with other web technologies, there are discrepancies in how browsers handle JavaScript (particularly on non-desktop devices), and some users opt to turn it off entirely. The first rule in progressive enhancement is to make sure basic functionality—such as linking from page to page or accomplishing essential tasks like data submission via forms—is intact even when JavaScript is off. In this way, you ensure the baseline experience, and enhance it when JavaScript is available.

For Further Reading

• There is no better introduction to the progressive enhancement approach than the book Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement, 2nd Edition, by Aaron Gustafson (New Riders).
• The Uncertain Web: Web Development in a Changing Landscape by Rob Larson (O’Reilly).
• Once you have more chops, the book Designing with Progressive Enhancement by Todd Parker, Patty Toland, Scott Jehl, and Maggie Costello Wachs (New Riders) is an excellent deep-dive into techniques and best practices. Read more about it at filamentgroup.com/dwpe/.

Responsive Web Design

By default, most browsers on small devices such as smartphones and tablets shrink a web page down to fit the screen and provide mechanisms for zooming and moving around the page. Although it technically works, it is not a great experience. The text is too small to read, the links are too small to tap, and all that zooming and panning around is distracting.

Responsive Web Design (RWD) is a strategy for providing appropriate layouts to devices based on the size of the viewport (browser window). The key to Responsive Web Design is serving a single HTML document (with one URL) to all devices, but applying different style sheets based on the screen size in order to provide the most optimized layout for that device. For example, when the page is viewed on a smartphone, it appears in one column with large links for easy tapping. But when that same page is viewed on a large desktop browser, the content rearranges into multiple columns with traditional navigation elements. It’s like magic! (Except that it’s actually just CSS.)

The web design community has been abuzz about responsive design since Ethan Marcotte first wrote about it and coined the phrase in his article “Responsive Web Design” on A List Apart in 2010 (alistapart.com/articles/responsive-web-design/). It’s become one of the primary tools we use to cope with unknown viewport size.

Figure 3-3 shows some examples of responsive sites at the typical dimensions for a desktop monitor, tablet, and smartphone. You can see many more inspirational examples at the Media Queries gallery site (mediaqueri.es). Try opening one of the responsive sites in your browser and then resizing the window narrow and wide. Watch as the layout changes based on window size. Très cool.

Responsive Web Design helps with matters of layout, but it is not a solution to all mobile web design challenges. The fact is that providing the best experiences for your users and their chosen device may require optimizations that go beyond adjusting the look and feel. You can better address some problems by using the server to detect the device and its capabilities and then making decisions on what to send back.

For some sites and services, it may be preferable to build a separate mobile site (see the “M-dot Sites” sidebar) with a customized interface and feature set that takes advantage of phone capabilities like geolocation. That said, although responsive design won’t fix everything, it is an important part of the solution for delivering satisfactory experiences on a wide variety of browsers.

For Further Reading

I’ll cover Responsive Web Design in more detail in Chapter 17, Responsive Web Design, once you have more code experience under your belt. There you will find plenty of resources to continue your responsive design education.

One Web for All (Accessibility)

We’ve been talking about the daunting number of browsers in use today, but so far, we’ve only addressed visual browsers controlled with mouse pointers or fingertips. It is critical, however, to keep in mind that people access the web in many different ways—with a keyboard, mouse, voice commands, screen readers, Braille output, magnifiers, joysticks, foot pedals, and so on. Web designers must build pages in a manner that creates as few barriers as possible to getting to information, regardless of the user’s ability and the device used to access the web. In other words, you must design for accessibility.

Although intended for users with disabilities such as poor vision or limited mobility, the techniques and strategies developed for accessibility also benefit other users with less-than-optimum browsing experiences. Accessible sites are also more effectively indexed by search engines such as Google. Making your site accessible is well worth the extra effort.

There are four broad categories of disabilities that affect how people interact with their computers and the information on them:

Vision impairment

People with low or no vision may use an assistive device such as a screen reader, Braille display, or a screen magnifier to get content from the screen. They may also simply use the browser’s text zoom function to make the text large enough to read.

Mobility impairment

Users with limited or no use of their hands may use special devices such as modified mice and keyboards, foot pedals, voice commands, or joysticks to navigate the web and enter information.

Auditory impairment

Users with limited or no hearing will miss out on audio aspects of multimedia, so it is necessary to provide alternatives, such as transcripts for audio tracks or captions for video.

Cognitive impairment

Users with memory, reading comprehension, problem solving, and attention limitations benefit when sites are designed simply and clearly. These qualities are helpful to anyone using your site.

The W3C started the Web Accessibility Initiative (WAI) to address the need to make the web usable for everyone. The WAI site (www.w3.org/WAI) is an excellent starting point for learning more about web accessibility. One of the documents produced by the WAI to help developers create accessible sites is the Web Content Accessibility Guidelines (WCAG and WCAG 2.0). You can read them all at www.w3.org/WAI/intro/wcag.php. The US government based its Section 508 accessibility guidelines on the Priority 1 points of the WCAG (see the sidebar “Government Accessibility Requirements: Section 508”). All sites benefit from these guidelines, but if you are designing a government site, adherence is a requirement.

Another W3C effort is the WAI-ARIA (Accessible Rich Internet Applications) spec, which addresses the accessibility of web applications that include dynamically generated content, scripting, and advanced interface elements that are particularly confounding to assistive devices. The ARIA Recommendation defines a number of roles for content and widgets that authors can explicitly apply using the role attribute. Roles include menubar, progressbar, slider, timer, and tooltip, to name just a few. For the complete list of roles, go to www.w3.org/TR/wai-aria/#role_definitions.

For Further Reading

The following resources are good starting points for further exploration of web accessibility:

• The Web Accessibility Initiative (WAI), www.w3.org/WAI
• WebAIM: Web Accessibility in Mind, www.webaim.org
• Accessibility Handbook: Making 508 Compliant Websites by Katie Cunningham (O’Reilly)
• Universal Design for Web Applications: Web Applications That Reach Everyone by Wendy Chisholm and Matt May (O’Reilly)

  US Government Accessibility Requirements: Section 508

  If you create a site receiving federal funding from the US government, you are required by law to comply with the Section 508 guidelines, which ensure that electronic information and technology are available to people with disabilities. State and other publicly funded sites may also be required to comply.

  The following guidelines, excerpted from the Section 508 Standards at www.section508.gov, provide a good checklist for basic accessibility for all websites:

  1. A text equivalent for non-text elements shall be provided (e.g., via the “alt” attribute or in element content).
  2. Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.
  3. Web pages shall be designed so that all information conveyed with color is also available without color—for example, from context or markup.
  4. Documents shall be organized so they are readable without requiring an associated style sheet.
  5. Row and column headers shall be identified for data tables.
  6. Markup shall be used to associate data and header cells for tables with two or more levels of row or column headers.
  7. Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.
  8. When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.
  9. When a web page requires that an applet, plug-in, or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).
  10. When electronic forms are designed to be completed online, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
  11. A method shall be provided that permits users to skip repetitive navigation links.
  12. When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

The Need for Speed (Site Performance)

Although the number of users accessing the internet on slow dial-up connections is shrinking (3–5% in the US as of this writing), the percentage of folks using mobile phones to access the web is increasing dramatically; and for some sectors, such as social media and search, mobile has already exceeded desktop usage. If you have a smartphone, then you know how frustrating it is to wait for a web page to fully display over a cellular data connection.

Site performance is critical regardless of how your users access your site. A study by Google in 2009¹ showed that the addition of just 100 to 400 milli­seconds to their search results page resulted in reduced searches (–0.2 to –0.6%). Amazon.com showed that reducing page load times by just 100ms resulted in a 1% increase in revenue.² Other studies show that users expect a site to load in under 2 seconds, and nearly a third of your audience will leave your site for another if it doesn’t. Furthermore, those people aren’t likely to come back. Google has added site speed to its search algorithm, so if your site is a slowpoke, it’s not likely to show up in that coveted first screen of results. The takeaway here is that site performance (down to the millisecond!) matters a lot.

There are many things you can do to improve the performance of your site, and they fall under two broad categories: limiting file sizes and reducing the number of requests to the server. The following list only scratches the surface for site optimization, but it gives you a general idea of what can be done:

• Optimize images so they are the smallest file size possible without sacrificing quality. You’ll learn image optimization techniques in Chapter 24, Image Asset Production.
• Streamline HTML markup, avoiding unnecessary levels of nested elements.
• Minimize HTML and CSS documents by removing extra character spaces and line returns.
• Keep JavaScript to a minimum.
• Add scripts in such a way that they load in parallel with other page assets and don’t block rendering.
• Don’t load unnecessary assets (such as images, scripts, or JavaScript libraries).
• Reduce the number of times the browser makes requests of the server (known as HTTP requests).

Every trip to the server in the form of an HTTP request takes a few milli­seconds, and those milliseconds can add up. All those little Twitter widgets, Facebook Like buttons, and advertisements can make dozens of server requests each. You may be surprised to see how many server requests even a simple site makes.

If you’d like to see for yourself, you can use the Network tool available with the Developer tools in Chrome, Safari, or Firefox. The Network tool displays each request to the server and how many milliseconds it took. Here’s how you use it in Chrome (but all the browsers work similarly):

1. Launch the Chrome browser and go to any web page.
2. Go to the View menu and select Developer → Developer Tools. A panel will open at the bottom of the browser.
3. Select the Network tab in the tools view and load a web page. The chart (commonly referred to as a waterfall chart) shows you all the requests made and assets downloaded. The columns on the right show the amount of time each request took in milliseconds. At the bottom of the chart, you can see a summary of the number of requests made and the total amount of data transferred.

Figure 3-5 shows a portion of the performance waterfall chart for oreilly.com. You can poke around any site on the web this way. It can be very educational.

I won’t address site performance in deep technical detail in this book, but I do want you to remember the importance of keeping file sizes as small as possible and eliminating unnecessary server requests in your web design work.

For Further Reading

There are other techniques that are too technical for this book (and frankly, for me), and I figure if you are reading this book, you are probably not quite ready to become a site performance wizard. But when you are ready to take it on, here are some resources that should help:

• Lara Hogan has assembled a list of performance-related studies, tools, and resources at larahogan.me/design. You can also read her book, Designing for Performance (O’Reilly), there for free.
• High Performance Mobile Web: Best Practices for Optimizing Mobile Web Apps by Maximiliano Firtman (O’Reilly) covers optimization methods and tools to check your progress.
• Google’s site Make the Web Faster (code.google.com/speed/) is an excellent first stop for learning about site optimization. It compiles a number of excellent tutorials and articles as well as tools for measuring site speed.

  More Site Performance Tools

  Try some of these tools for testing site performance:

  • WebPageTest (webpagetest.org) is a tool that was originally developed for AOL, but is now available for all to use for free under an open source license. Just type in a URL, and WebPagetest returns a waterfall diagram, screenshot, and other statistics.
  • Google’s PageSpeed Insights (developers.google.com/speed/pagespeed/insights/) is another service that analyzes the performance of any site you point it to. It also generates suggestions for making your page load faster.
  • Yahoo!’s freely available YSlow tool (yslow.org) analyzes a site according to 23 rules of web performance, and then gives the site a grade and suggestions for improvement.

Test Yourself

Here are a few questions that check your knowledge of the Big Concepts. If you are stumped, you can find the answers in Appendix A.

1. List at least two unknown factors you need to consider when designing and developing a site.
2. Match the technology or practice on the left with the problem it best addresses:

   1. ____ Progressive enhancement	a. Assistive reading and input devices
   2. ____ Server-side detection	b. Slow connection speeds
   3. ____ Responsive design	c. All levels of browser capabilities
   4. ____ WAI-ARIA	d. Determining which device is being used
   5. ____ Site performance optimization	e. A variety of screen sizes

3. Web accessibility strategies take into account four broad categories of disabilities. Name at least three, and provide a measure you might take to ensure content is accessible for each.
4. When would you use a waterfall chart?

Part II. HTML for STRUCTURE

II

HTML for STRUCTURE

4. Creating a Simple Page

4

Creating a Simple Page

(HTML Overview)

Part I provided a general overview of the web design environment. Now that we’ve covered the big concepts, it’s time to roll up our sleeves and start creating a real web page. It will be an extremely simple page, but even the most complicated pages are based on the principles described here.

In this chapter, we’ll create a web page step-by-step so you can get a feel for what it’s like to mark up a document with HTML tags. The exercises allow you to work along.

This is what I want you to get out of this chapter:

• Get a feel for how markup works, including an understanding of elements and attributes.
• See how browsers interpret HTML documents.
• Learn how HTML documents are structured.
• Get a first glimpse of a style sheet in action.

Don’t worry about learning the specific text elements or style sheet rules at this point; we’ll get to those in the following chapters. For now, just pay attention to the process, the overall structure of the document, and the new terminology.

A Web Page, Step-By-Step

You got a look at an HTML document in Chapter 2, How the Web Works, but now you’ll get to create one yourself and play around with it in the browser. The demonstration in this chapter has five steps that cover the basics of page production:

Step 1: Start with content. As a starting point, we’ll write up raw text content and see what browsers do with it.

Step 2: Give the document structure. You’ll learn about HTML element syntax and the elements that set up areas for content and metadata.

Step 3: Identify text elements. You’ll describe the content using the appropriate text elements and learn about the proper way to use HTML.

Step 4: Add an image. By adding an image to the page, you’ll learn about attributes and empty elements.

Step 5: Change how the text looks with a style sheet. This exercise gives you a taste of formatting content with Cascading Style Sheets.

By the time we’re finished, you’ll have written the document for the page shown in Figure 4-1. It’s not very fancy, but you have to start somewhere.

We’ll be checking our work in a browser frequently throughout this demonstration—probably more than you would in real life. But because this is an introduction to HTML, it’s helpful to see the cause and effect of each small change to the source file along the way.

Launch a Text Editor

In this chapter and throughout the book, we’ll be writing out HTML documents by hand, so the first thing we need to do is launch a text editor. The text editor that is provided with your operating system, such as Notepad (Windows) or TextEdit (Macintosh), will do for these purposes. Other text editors are fine as long as you can save plain-text files with the .html extension. If you have a visual web-authoring tool such as Dreamweaver, set it aside for now. I want you to get a feel for marking up a document manually (see the sidebar “HTML the Hard Way”).

This section shows how to open new documents in Notepad and TextEdit. Even if you’ve used these programs before, skim through for some special settings that will make the exercises go more smoothly. We’ll start with Notepad; Mac users can jump ahead.

Creating a New Document in Notepad (Windows)

These are the steps to creating a new document in Notepad on Windows 10 (Figure 4-2):

1. Search for “Notepad” to access it quickly. Click on Notepad to open a new document window, and you’re ready to start typing. 1
2. Next, make the extensions visible. This step is not required to make HTML documents, but it will help make the file types clearer at a glance. Open the File Explorer, select the View tab, and then select the Options button on the right. In the Folder Options panel, select the View tab again. 2
3. Find “Hide extensions for known file types” and uncheck that option. 3
4. Click OK to save the preference 4, and the file extensions will now be visible.

Creating a New Document in TextEdit (macOS)

By default, TextEdit creates rich-text documents—that is, documents that have hidden style-formatting instructions for making text bold, setting font size, and so on. You can tell that TextEdit is in rich-text mode when it has a formatting toolbar at the top of the window (plain-text mode does not). HTML documents need to be plain-text documents, so we’ll need to change the format, as shown in this example (Figure 4-3):

1. Use the Finder to look in the Applications folder for TextEdit. When you’ve found it, double-click the name or icon to launch the application.
2. In the initial TextEdit dialog box, click the New Document button in the bottom-left corner. If you see the text formatting menu and tab ruler at the top of the Untitled document, you are in rich-text mode 1. If you don’t, you are in plain-text mode 2. Either way, there are some preferences you need to set.
3. Close that document, and open the Preferences dialog box from the TextEdit menu.
4. Change these preferences:

   On the New Document tab, select Plain text 3. Under Options, deselect all of the automatic formatting options 4.

   On the Open and Save tab, select Display HTML files as HTML Code 5 and deselect “Add ‘.txt’ extensions to plain text files” 6. The rest of the defaults should be fine.

5. When you are done, click the red button in the top-left corner.
6. Now create a new document by selecting File → New. The formatting menu will no longer be there, and you can save your text as an HTML document. You can always convert a document back to rich text by selecting Format → Make Rich Text when you are not using TextEdit for HTML.

Step 1: Start with Content

Now that we have our new document, it’s time to get typing. A web page is all about content, so that’s where we begin our demonstration. Exercise 4-1 walks you through entering the raw text content and saving the document in a new folder.

Learning from Step 1

Our page isn’t looking so good (Figure 4-5). The text is all run together into one block—that’s not how it looked when we typed it into the original document. There are a couple of lessons to be learned here. The first thing that is apparent is that the browser ignores line breaks in the source document. The sidebar “What Browsers Ignore” lists other types of information in the source document that are not displayed in the browser window.

Second, we see that simply typing in some content and naming the document .html is not enough. While the browser can display the text from the file, we haven’t indicated the structure of the content. That’s where HTML comes in. We’ll use markup to add structure: first to the HTML document itself (coming up in Step 2), then to the page’s content (Step 3). Once the browser knows the structure of the content, it can display the page in a more meaningful way.

long,      long        ago

long, long ago

Step 2: Give the HTML Document Structure

We have our content saved in an HTML document—now we’re ready to start marking it up.

The Anatomy of an HTML Element

Back in Chapter 2 you saw examples of elements with an opening tag (<p> for a paragraph, for example) and a closing tag (</p>). Before we start adding tags to our document, let’s look at the anatomy of an HTML element (its syntax) and firm up some important terminology. A generic container element is labeled in Figure 4-6.

Elements are identified by tags in the text source. A tag consists of the element name (usually an abbreviation of a longer descriptive name) within angle brackets (< >). The browser knows that any text within brackets is hidden and not displayed in the browser window.

The element name appears in the opening tag (also called a start tag) and again in the closing (or end) tag preceded by a slash (/). The closing tag works something like an “off” switch for the element. Be careful not to use the similar backslash character in end tags (see the tip “Slash Versus Backslash”).

The tags added around content are referred to as the markup. It is important to note that an element consists of both the content and its markup (the start and end tags). Not all elements have content, however. Some are empty by definition, such as the img element used to add an image to the page. We’ll talk about empty elements a little later in this chapter.

One last thing: capitalization. In HTML, the capitalization of element names is not important (it is not case-sensitive). So <img>, <Img>, and <IMG> are all the same as far as the browser is concerned. However, most developers prefer the consistency of writing element names in all lowercase (see Note), as I will be doing throughout this book.

Basic Document Structure

Figure 4-8 shows the recommended minimal skeleton of an HTML document. I say “recommended” because the only element that is required in HTML is the title. But I feel it is better, particularly for beginners, to explicitly organize documents into metadata (head) and content (body) areas. Let’s take a look at what’s going on in this minimal markup example.

1. I don’t want to confuse things, but the first line in the example isn’t an element at all. It is a document type declaration (also called DOCTYPE declaration) that lets modern browsers know which HTML specification to use to interpret the document. This DOCTYPE identifies the document as written in HTML5.
2. The entire document is contained within an html element. The html element is called the root element because it contains all the elements in the document, and it may not be contained within any other element.
3. Within the html element, the document is divided into a head and a body. The head element contains elements that pertain to the document that are not rendered as part of the content, such as its title, style sheets, scripts, and metadata.
4. meta elements provide document metadata, information about the document. In this case, it specifies the character encoding (a standardized collection of letters, numbers, and symbols) used in the document as Unicode version UTF-8 (see the sidebar “Introducing Unicode”). I don’t want to go into too much detail on this right now, but know that there are many good reasons for specifying the charset in every document, so I have included it as part of the minimal document markup. Other types of metadata provided by the meta element are the author, keywords, publishing status, and a description that can be used by search engines.
5. Also in the head is the mandatory title element. According to the HTML specification, every document must contain a descriptive title.
6. Finally, the body element contains everything that we want to show up in the browser window.

   Introducing Unicode

   All the characters that make up languages are stored in computers as numbers. A standardized collection of characters with their reference numbers (code points) is called a coded character set, and the way in which those characters are converted to bytes for use by computers is the character encoding. In the early days of computing, computers used limited character sets such as ASCII that contained 128 characters (letters from Latin languages, numbers, and common symbols). The early web used the Latin-1 (ISO 8859-1) character encoding that included 256 Latin characters from most Western languages. But given the web was “worldwide,” it was clearly not sufficient.

   Enter Unicode. Unicode (also called the Universal Character Set) is a super-character set that contains over 136,000 characters (letters, numbers, symbols, ideograms, logograms, etc.) from all active modern languages. You can read all about it at unicode.org. Unicode has three standard encodings—UTF-8, UTF-16, and UTF-32—that differ in the number of bytes used to represent the characters (1, 2, or 4, respectively).

   HTML5 uses the UTF-8 encoding by default, which allows wide-ranging languages to be mixed within a single document. It is always a good idea to declare the character encoding for a document with the meta element, as shown in the previous example. Your server also needs to be configured to identify HTML documents as UTF-8 in the HTTP header (information about the document that the server sends to the user agent). You can ask your server administrator to confirm the encoding of the HTML documents.

Are you ready to start marking up the Black Goose Bistro home page? Open the index.html document in your text editor and move on to Exercise 4-2.

Not much has changed in the bistro page after setting up the document, except that the browser now displays the title of the document in the top bar or tab (Figure 4-9). If someone were to bookmark this page, that title would be added to their Bookmarks or Favorites list as well (see the sidebar “Don’t Forget a Good Title”). But the content still runs together because we haven’t given the browser any indication of how it should be structured. We’ll take care of that next.

Step 3: Identify Text Elements

With a little markup experience under your belt, it should be a no-brainer to add the markup for headings and subheads (h1 and h2), paragraphs (p), and emphasized text (em) to our content, as we’ll do in Exercise 4-3. However, before we begin, I want to take a moment to talk about what we’re doing and not doing when marking up content with HTML.

Mark It Up Semantically

The purpose of HTML is to add meaning and structure to the content. It is not intended to describe how the content should look (its presentation).

Your job when marking up content is to choose the HTML element that provides the most meaningful description of the content at hand. In the biz, we call this semantic markup. For example, the most important heading at the beginning of the document should be marked up as an h1 because it is the most important heading on the page. Don’t worry about what it looks like…you can easily change that with a style sheet. The important thing is that you choose elements based on what makes the most sense for the content.

In addition to adding meaning to content, the markup gives the document structure. The way elements follow each other or nest within one another creates relationships between them. You can think of this structure as an outline (its technical name is the DOM, for Document Object Model). The underlying document hierarchy gives browsers cues on how to handle the content. It is also the foundation upon which we add presentation instructions with style sheets and behaviors with JavaScript.

Although HTML was intended to be used strictly for meaning and structure since its creation, that mission was somewhat thwarted in the early years of the web. With no style sheet system in place, HTML was extended to give authors ways to change the appearance of fonts, colors, and alignment using markup alone. Those presentational extras are still out there, so you may run across them if you view the source of older sites or a site made with old tools. In this book, however, I’ll focus on using HTML the right way, in keeping with the contemporary standards-based, semantic approach to web design.

OK, enough lecturing. It’s time to get to work on that content in Exercise 4-3.

Now we’re getting somewhere. With the elements properly identified, the browser can now display the text in a more meaningful manner. There are a few significant things to note about what’s happening in Figure 4-10.

Block and Inline Elements

Although it may seem like stating the obvious, it’s worth pointing out that the heading and paragraph elements start on new lines and do not run together as they did before. That is because by default, headings and paragraphs display as block elements. Browsers treat block elements as though they are in little rectangular boxes, stacked up in the page. Each block element begins on a new line, and some space is also usually added above and below the entire element by default. In Figure 4-11, the edges of the block elements are outlined in red.

By contrast, look at the text we marked up as emphasized (em, outlined in blue in Figure 4-11). It does not start a new line, but rather stays in the flow of the paragraph. That is because the em element is an inline element (also called a text-level semantic element or phrasing element). Inline elements do not start new lines; they just go with the flow.

<!-- This is a comment -->

<!-- This is a   multiple-line comment   that ends here. -->

<!-- start global nav -->

<ul>

 …

</ul>

<!-- end global nav -->

Default Styles

The other thing that you will notice about the marked-up page in Figures 4-10 and 4-11 is that the browser makes an attempt to give the page some visual hierarchy by making the first-level heading the biggest and boldest thing on the page, with the second-level headings slightly smaller, and so on.

How does the browser determine what an h1 should look like? It uses a style sheet! All browsers have their own built-in style sheets (called user agent style sheets in the spec) that describe the default rendering of elements. The default rendering is similar from browser to browser (for example, h1s are always big and bold), but there are some variations (the blockquote element for long quotes may or may not be indented).

If you think the h1 is too big and clunky as the browser renders it, just change it with your own style sheet rule. Resist the urge to mark up the heading with another element just to get it to look better—for example, using an h3 instead of an h1 so it isn’t as large. In the days before ubiquitous style sheet support, elements were abused in just that way. You should always choose elements based on how accurately they describe the content, and don’t worry about the browser’s default rendering.

We’ll fix the presentation of the page with style sheets in a moment, but first, let’s add an image to the page.

Step 4: Add an Image

What fun is a web page with no images? In Exercise 4-4, we’ll add an image to the page with the img element. Images will be discussed in more detail in Chapter 7, Adding Images, but for now, they give us an opportunity to introduce two more basic markup concepts: empty elements and attributes.

Empty Elements

So far, nearly all of the elements we’ve used in the Black Goose Bistro home page have followed the syntax shown in Figure 4-6: a bit of text content surrounded by start and end tags.

A handful of elements, however, do not have content because they are used to provide a simple directive. These elements are said to be empty. The image element (img) is an example of an empty element. It tells the browser to get an image file from the server and insert it at that spot in the flow of the text. Other empty elements include the line break (br), thematic breaks (hr, a.k.a. “horizontal rules”), and elements that provide information about a document but don’t affect its displayed content, such as the meta element that we used earlier.

Figure 4-12 shows the very simple syntax of an empty element (compare it to Figure 4-6).

Attributes

Let’s get back to adding an image with the empty img element. Obviously, an <img> tag is not very useful by itself—it doesn’t indicate which image to use. That’s where attributes come in. Attributes are instructions that clarify or modify an element. For the img element, the src (short for “source”) attribute is required, and specifies the location (URL) of the image file.

The syntax for an attribute is as follows:

attributename="value"

Attributes go after the element name, separated by a space. In non-empty elements, attributes go in the opening tag only:

<element attributename="value"><element attributename="value">Content</element>

You can also put more than one attribute in an element in any order. Just keep them separated with spaces:

<element attribute1="value" attribute2="value">

Figure 4-13 shows an img element with its required attributes labeled.

Here’s what you need to know about attributes:

• Attributes go after the element name in the opening tag only, never in the closing tag.
• There may be several attributes applied to an element, separated by spaces in the opening tag. Their order is not important.
• Most attributes take values, which follow an equals sign (=). In HTML, some attribute values are single descriptive words. For example, the checked attribute, which makes a form checkbox checked when the form loads, is equivalent to checked="checked". You may hear this type of attribute called a Boolean attribute because it describes a feature that is either on or off.
• A value might be a number, a word, a string of text, a URL, or a measurement, depending on the purpose of the attribute. You’ll see examples of all of these throughout this book.
• Wrapping attribute values in double quotation marks is a strong convention, but note that quotation marks are not required and may be omitted. In addition, either single or double quotation marks are acceptable as long as the opening and closing marks match. Note that quotation marks in HTML files need to be straight ("), not curly (”).
• The attribute names and values available for each element are defined in the HTML specifications; in other words, you can’t make up an attribute for an element.
• Some attributes are required, such as the src and alt attributes in the img element. The HTML specification also defines which attributes are required in order for the document to be valid.

Now you should be more than ready to try your hand at adding the img element with its attributes to the Black Goose Bistro page in Exercise 4-4. We’ll throw a few line breaks in there as well.

Step 5: Change the Look with a Style Sheet

Depending on the content and purpose of your website, you may decide that the browser’s default rendering of your document is perfectly adequate. However, I think I’d like to pretty up the Black Goose Bistro home page a bit to make a good first impression on potential patrons. “Prettying up” is just my way of saying that I’d like to change its presentation, which is the job of Cascading Style Sheets (CSS).

In Exercise 4-5, we’ll change the appearance of the text elements and the page background by using some simple style sheet rules. Don’t worry about understanding them all right now. We’ll get into CSS in more detail in Part III. But I want to at least give you a taste of what it means to add a “layer” of presentation onto the structure we’ve created with our markup.

We’re finished with the Black Goose Bistro page. Not only have you written your first web page, complete with a style sheet, but you’ve also learned about elements, attributes, empty elements, block and inline elements, the basic structure of an HTML document, and the correct use of markup along the way. Not bad for one chapter!

When Good Pages Go Bad

The previous demonstration went smoothly, but it’s easy for small things to go wrong when you’re typing out HTML markup by hand. Unfortunately, one missed character can break a whole page. I’m going to break my page on purpose so we can see what happens.

What if I had neglected to type the slash in the closing emphasis tag (</em>)? With just one character out of place (Figure 4-17), the remainder of the document displays in emphasized (italic) text. That’s because without that slash, there’s nothing telling the browser to turn “off” the emphasized formatting, so it just keeps going (see Note).

I’ve fixed the slash, but this time, let’s see what would have happened if I had accidentally omitted a bracket from the end of the first <h2> tag (Figure 4-18).

See how the headline is missing? That’s because without the closing tag bracket, the browser assumes that all the following text—all the way up to the next closing bracket (>) it finds—is part of the <h2> opening tag. Browsers don’t display any text within a tag, so my heading disappeared. The browser just ignored the foreign-looking element name and moved on to the next element.

Making mistakes in your first HTML documents and fixing them is a great way to learn. If you write your first pages perfectly, I’d recommend fiddling with the code to see how the browser reacts to various changes. This can be extremely useful in troubleshooting pages later. I’ve listed some common problems in the sidebar “Having Problems?” Note that these problems are not specific to beginners. Little stuff like this goes wrong all the time, even for the pros.

Validating Your Documents

One way that professional web developers catch errors in their markup is to validate their documents. What does that mean? To validate a document is to check your markup to make sure that you have abided by all the rules of whatever version of HTML you are using. Documents that are error-free are said to be valid. It is strongly recommended that you validate your documents, especially for professional sites. Valid documents are more consistent on a variety of browsers, they display more quickly, and they are more accessible.

Right now, browsers don’t require documents to be valid (in other words, they’ll do their best to display them, errors and all), but anytime you stray from the standard, you introduce unpredictability in the way the page is handled by browsers or alternative devices.

So how do you make sure your document is valid? You could check it yourself or ask a friend, but humans make mistakes, and you aren’t expected to memorize every minute rule in the specifications. Instead, use a validator, software that checks your source against the HTML version you specify. These are some of the things validators check for:

• The inclusion of a DOCTYPE declaration. Without it the validator doesn’t know which version of HTML to validate against:
• An indication of the character encoding for the document.
• The inclusion of required rules and attributes.
• Non-standard elements.
• Mismatched tags.
• Nesting errors (incorrectly putting elements inside other elements).
• Typos and other minor errors.

Developers use a number of helpful tools for checking and correcting errors in HTML documents. The best web-based validator is at html5.validator.nu. There you can upload a file or provide a link to a page that is already online. Figure 4-19 shows the report the validator generates when I upload the version of the Bistro index.html file that doesn’t have any markup. For this document, there are a number of missing elements that keep this document from being valid. It also shows the problem source code and provides an explanation of how the code should appear. Pretty darned handy!

Built-in browser developer tools for Safari and Chrome also have validators so you can check your work on the fly. Some code editors have validators built in as well.

Test Yourself

Now is a good time to make sure you understand the basics of markup. Use what you’ve learned in this chapter to answer the following questions. Answers are in Appendix A.

1. What is the difference between a tag and an element?
2. Write out the recommended minimal markup for an HTML5 document.
3. Indicate whether each of these filenames is an acceptable name for a web document by circling “Yes” or “No.” If it is not acceptable, provide the reason:

   a. Sunflower.html	Yes	No
   b. index.doc	Yes	No
   c. cooking home page.html	Yes	No
   d. Song_Lyrics.html	Yes	No
   e. games/rubix.html	Yes	No
   f. %whatever.html	Yes	No

4. All of the following markup examples are incorrect. Describe what is wrong with each one, and then write it correctly.
   1. <img "birthday.jpg">
   2. <em>Congratulations!<em>

   3. <a href="file.html">linked text</a href="file.html">

   4. <p>This is a new paragraph<\p>
5. How would you mark up this comment in an HTML document so that it doesn’t display in the browser window?

      product list begins here

Element Review: HTML Document Setup

This chapter introduced the elements that establish metadata and content portions of an HTML document. The remaining elements introduced in the exercises will be treated in more depth in the following chapters.

body

head

html

meta

title

5. Marking Up Text

5

Marking Up Text

Once your content is ready to go (you’ve proofread it, right?) and you’ve added the markup to structure the document (<!DOCTYPE>, html, head, title, meta charset, and body), you are ready to identify the elements in the content. This chapter introduces the elements you have to choose from for marking up text. There probably aren’t as many of them as you might think, and really just a handful that you’ll use with regularity. That said, this chapter is a big one and covers a lot of ground.

As we begin our tour of elements, I want to reiterate how important it is to choose elements semantically—that is, in a way that most accurately describes the content’s meaning. If you don’t like how it looks, change it with a style sheet. A semantically marked-up document ensures your content is available and accessible in the widest range of browsing environments, from desktop computers and mobile devices to assistive screen readers. It also allows non-human readers, such as search engine indexing programs, to correctly parse your content and make decisions about the relative importance of elements on the page.

With these principles in mind, it is time to meet the HTML text elements, starting with the most basic element of them all, the humble paragraph.

Paragraphs

<p>…</p>

Paragraph element

Paragraphs are the most rudimentary elements of a text document. Indicate a paragraph with the p element by inserting an opening <p> tag at the beginning of the paragraph and a closing </p> tag after it, as shown in this example:

<p>Serif typefaces have small slabs at the ends of letter strokes. In general, serif fonts can make large amounts of text easier to read.</p>


<p>Sans-serif fonts do not have serif slabs; their strokes are square on the end. Helvetica and Arial are examples of sans-serif fonts. In general, sans-serif fonts appear sleeker and more modern.</p>

Visual browsers nearly always display paragraphs on new lines with a bit of space between them by default (to use a term from CSS, they are displayed as a block). Paragraphs may contain text, images, and other inline elements (called phrasing content), but they may not contain headings, lists, sectioning elements, or any elements that typically display as blocks by default.

Technically, it is OK to omit the closing </p> tag because it is not required in order for the document to be valid. A browser just assumes it is closed when it encounters the next block element. Many web developers, including myself, prefer to close paragraphs and all elements for the sake of consistency and clarity. I recommend folks who are just learning markup do the same.

Headings

In the last chapter, we used the h1 and h2 elements to indicate headings for the Black Goose Bistro page. There are actually six levels of headings, from h1 to h6. When you add headings to content, the browser uses them to create a document outline for the page. Assistive reading devices such as screen readers use the document outline to help users quickly scan and navigate through a page. In addition, search engines look at heading levels as part of their algorithms (information in higher heading levels may be given more weight). For these reasons, it is a best practice to start with the Level 1 heading (h1) and work down in numerical order, creating a logical document structure and outline.

This example shows the markup for four heading levels. Additional heading levels would be marked up in a similar manner.

<h1>Type Design</h1> 
<h2>Serif Typefaces</h2><p>Serif typefaces have small slabs at the ends of letter strokes. In general, serif fonts can make large amounts of text easier to read.</p> <h3>Baskerville</h3> <h4>Description</h4><p>Description of the Baskerville typeface.</p> <h4>History</h4><p>The history of the Baskerville typeface.</p> <h3>Georgia</h3><p>Description and history of the Georgia typeface.</p> <h2>Sans-serif Typefaces</h2><p>Sans-serif typefaces do not have slabs at the ends of strokes.</p>

The markup in this example would create the following document outline:

By default, the headings in our example display in bold text, starting in very large type for h1s, with each consecutive level in smaller text, as shown in Figure 5-1. You can use a style sheet to change their appearance.

Thematic Breaks (Horizontal Rule)

If you want to indicate that one topic has completed and another one is beginning, you can insert what the spec calls a “paragraph-level thematic break” with the hr element. The hr element adds a logical divider between sections of a page or paragraphs without introducing a new heading level.

In older HTML versions, hr was defined as a “horizontal rule” because it inserts a horizontal line on the page. Browsers still render hr as a 3-D shaded rule and put it on a line by itself with some space above and below by default; but in the HTML5 spec, it has a new semantic name and definition. If a decorative line is all you’re after, it is better to create a rule by specifying a colored border before or after an element with CSS.

hr is an empty element—you just drop it into place where you want the thematic break to occur, as shown in this example and Figure 5-2:

<h3>Times</h3><p>Description and history of the Times typeface.</p><hr><h3>Georgia</h3><p>Description and history of the Georgia typeface.</p>

Lists

Humans are natural list makers, and HTML provides elements for marking up three types of lists:

Unordered lists

Collections of items that appear in no particular order

Ordered lists

Lists in which the sequence of the items is important

Description lists

Lists that consist of name and value pairs, including but not limited to terms and definitions

All list elements—the lists themselves and the items that go in them—are displayed as block elements by default, which means that they start on a new line and have some space above and below, but that may be altered with CSS. In this section, we’ll look at each list type in detail.

Unordered Lists

Just about any list of examples, names, components, thoughts, or options qualifies as an unordered list. In fact, most lists fall into this category. By default, unordered lists display with a bullet before each list item, but you can change that with a style sheet, as you’ll see in a moment.

To identify an unordered list, mark it up as a ul element. The opening <ul> tag goes before the first list item, and the closing tag </ul> goes after the last item. Then, to mark up each item in the list as a list item (li), enclose it in opening and closing li tags, as shown in this example. Notice that there are no bullets in the source document. The browser adds them automatically (Figure 5-3).

The only thing that is permitted within an unordered list (that is, between the start and end ul tags) is one or more list items. You can’t put other elements in there, and there may not be any untagged text. However, you can put any type of content element within a list item (li):

<ul>  <li>Serif</li>  <li>Sans-serif</li>  <li>Script</li>  <li>Display</li>  <li>Dingbats</li></ul>

But here’s the cool part. We can take that same unordered list markup and radically change its appearance by applying different style sheets, as shown in Figure 5-4. In the figure, I’ve turned off the bullets, added bullets of my own, made the items line up horizontally, and even made them look like graphical buttons. The markup stays exactly the same.

<ol>  <li></li>  <li>    <ul>      <li></li>      <li></li>      <li></li>    </ul>
  </li></ol>

Ordered Lists

Ordered lists are for items that occur in a particular order, such as step-by-step instructions or driving directions. They work just like the unordered lists described earlier, but they are defined with the ol element (for “ordered list,” of course). Instead of bullets, the browser automatically inserts numbers before ordered list items (see Note), so you don’t need to number them in the source document. This makes it easy to rearrange list items without renumbering them.

Ordered list elements must contain one or more list item elements, as shown in this example and in Figure 5-5:

<ol>  <li>Gutenberg develops moveable type (1450s)</li>  <li>Linotype is introduced (1890s)</li>  <li>Photocomposition catches on (1950s)</li>  <li>Type goes digital (1980s)</li></ol>

If you want a numbered list to start at a number other than 1, you can use the start attribute in the ol element to specify another starting number, as shown here:

<ol start="17">  <li>Highlight the text with the text tool.</li>  <li>Select the Character tab.</li>  <li>Choose a typeface from the pop-up menu.</li></ol>

The resulting list items would be numbered 17, 18, and 19, consecutively.

Description Lists

Description lists are used for any type of name/value pairs, such as terms and their definitions, questions and answers, or other types of terms and their associated information. Their structure is a bit different from the other two lists that we just discussed. The whole description list is marked up as a dl element. The content of a dl is some number of dt elements indicating the names, and dd elements for their respective values. I find it helpful to think of them as “terms” (to remember the “t” in dt) and “definitions” (for the “d” in dd), even though that is only one use of description lists.

Here is an example of a list that associates forms of typesetting with their descriptions (Figure 5-6):

<dl>  <dt>Linotype</dt>  <dd>Line-casting allowed type to be selected, used, then recirculated into the machine automatically. This advance increased the speed of typesetting and printing dramatically.</dd>   <dt>Photocomposition</dt>  <dd>Typefaces are stored on film then projected onto photo-sensitive paper. Lenses adjust the size of the type.</dd>   <dt>Digital type</dt>  <dd><p>Digital typefaces store the outline of the font shape in a format such as Postscript. The outline may be scaled to any size for output.</p>	 <p>Postscript emerged as a standard due to its support of graphics and its early support on the Macintosh computer and Apple laser printer.</p>  </dd></dl>

The dl element is allowed to contain only dt and dd elements. You cannot put headings or content-grouping elements (like paragraphs) in names (dt), but the value (dd) can contain any type of flow content. For example, the last dd element in the previous example contains two paragraph elements (the awkward default spacing could be cleaned up with a style sheet).

It is permitted to have multiple definitions with one term and vice versa. Here, each term-description group has one term and multiple definitions:

<dl>  <dt>Serif examples</dt>  <dd>Baskerville</dd>  <dd>Goudy</dd>  <dt>Sans-serif examples</dt>  <dd>Helvetica</dd>  <dd>Futura</dd>  <dd>Avenir</dd></dl>

More Content Elements

We’ve covered paragraphs, headings, and lists, but there are a few more special text elements to add to your HTML toolbox that don’t fit into a neat category: long quotations (blockquote), preformatted text (pre), and figures (figure and figcaption). One thing these elements do have in common is that they are considered “grouping content” in the HTML5 spec (along with p, hr, the list elements, main, and the generic div, covered later in this chapter). The other thing they share is that browsers typically display them as block elements by default. The one exception is the newer main element, which is not recognized by any version of Internet Explorer (although it is supported in the Edge browser); see the sidebar “HTML5 Support in Internet Explorer,” later in this chapter, for a workaround.

Long Quotations

If you have a long quotation, a testimonial, or a section of copy from another source, mark it up as a blockquote element. It is recommended that content within blockquote elements be contained in other elements, such as paragraphs, headings, or lists, as shown in this example:

<p>Renowned type designer, Matthew Carter, has this to say about his profession:</p> <blockquote>  <p>Our alphabet hasn't changed in eons; there isn't much latitude in what a designer can do with the individual letters.</p>   <p>Much like a piece of classical music, the score is written down. It's not something that is tampered with, and yet, each conductor interprets that score differently. There is tension in the interpretation.</p></blockquote>

Figure 5-7 shows the default rendering of the blockquote example. This can be altered with CSS.

Preformatted Text

In the previous chapter, you learned that browsers ignore whitespace such as line returns and character spaces in the source document. But in some types of information, such as code examples or certain poems, the whitespace is important for conveying meaning. For content in which whitespace is semantically significant, use the preformatted text (pre) element. It is a unique element in that it is displayed exactly as it is typed—including all the carriage returns and multiple character spaces. By default, preformatted text is also displayed in a constant-width font (one in which all the characters are the same width, also called monospace), such as Courier; however, you can easily change the font with a style sheet rule.

The pre element in this example displays as shown in Figure 5-8. The second part of the figure shows the same content marked up as a paragraph (p) element for comparison.

<pre> This is               an             example of       text with a          lot of                           curious                           whitespace. </pre> 


<p>This is               an             example of       text with a          lot of                           curious                           whitespace. </p>

Figures

The figure element identifies content that illustrates or supports some point in the text. A figure may contain an image, a video, a code snippet, text, or even a table—pretty much anything that can go in the flow of web content. Content in a figure element should be treated and referenced as a self-contained unit. That means if a figure is removed from its original placement in the main flow (to a sidebar or appendix, for example), both the figure and the main flow should continue to make sense.

Although you can simply add an image to a page, wrapping it in figure tags makes its purpose explicitly clear semantically. It also works as a hook for applying special styles to figures but not to other images on the page:

<figure>   <img src="piechart.png" alt="chart showing fonts on mobile devices"></figure>

If you want to provide a text caption for the figure, use the figcaption element above or below the content inside the figure element. It is a more semantically rich way to mark up the caption than using a simple p element.

<figure>   <pre>      <code>        body {           background-color: #000;          color: red;        }      </code>    </pre>   <figcaption>Sample CSS rule.</figcaption></figure>

In Exercise 5-1, you’ll get a chance to mark up a document yourself and try out the basic text elements we’ve covered so far.

Tapenade (Olive Spread) This is a really simple dish to prepare and it’s always a big hit at parties. My father recommends: "Make this the night before so that the flavors have time to blend. Just bring it up to room temperature before you serve it. In the winter, try serving it warm." Ingredients  1 8oz. jar sundried tomatoes 2 large garlic cloves 2/3 c. kalamata olives 1 t. capers  Instructions  Combine tomatoes and garlic in a food processor. Blend until as smooth as possible. Add capers and olives. Pulse the motor a few times until they are incorporated, but still retain some texture. Serve on thin toast rounds with goat cheese and fresh basil garnish (optional).

Organizing Page Content

So far, the elements we’ve covered handle very specific tidbits of content: a paragraph, a heading, a figure, and so on. Prior to HTML5, there was no way to group these bits into larger parts other than wrapping them in a generic division (div) element (I’ll cover div in more detail later). HTML5 introduced new elements that give semantic meaning to sections of a typical web page or application (see Note), including main content (main), headers (header), footers (footer), sections (section), articles (article), navigation (nav), and tangentially related or complementary content (aside). Curiously, the spec lists the old address element as a section as well, so we’ll look at that one here too.

section, article, nav, aside, header, footer, main {   display: block;}

documencreateElement("section");

<!--[if lt IE 9]><script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/ html5shiv.min.js"></script ><![endif]-->

Main Content

Web pages these days are loaded with different types of content: mastheads, sidebars, ads, footers, more ads, even more ads, and so on. It is helpful to cut to the chase and explicitly point out the main content on the page. Use the main element to identify the primary content of a page or application. It helps screen readers and other assistive technologies know where the main content of the page begins and replaces the “Skip to main content” links that have been utilized in the past. The content of a main element should be unique to that page. In other words, headers, sidebars, and other elements that appear across multiple pages in a site should not be included in the main section:

<body><header>…</header><main>  <h1>Humanist Sans Serif</h1>  <!-- code continues -->
</main></body>

The W3C HTML5 specification states that pages should have only one main section and that it should not be nested within an article, aside, header, footer, or nav. Doing so will cause the document to be invalid.

The main element is the most recent addition to the roster of HTML5 grouping elements. You can use it and style it in most browsers, but for Internet Explorer (including version 11, the most current as of this writing), you’ll need to create the element with JavaScript and set its display to block with a style sheet, as discussed in the “HTML5 Support in Internet Explorer” sidebar. Note that main is supported in MS Edge.

Headers and Footers

Because web authors have been labeling header and footer sections in their documents for years, it was kind of a no-brainer that full-fledged header and footer elements would come in handy. Let’s start with headers.

Headers

The header element is used for introductory material that typically appears at the beginning of a web page or at the top of a section or article (we’ll get to those elements next). There is no specified list of what a header must or should contain; anything that makes sense as the introduction to a page or section is acceptable. In the following example, the document header includes a logo image, the site title, and navigation:

<body><header>  <img src="/images/logo.png" alt="logo">  <h1>Nuts about Web Fonts</h1>  <nav>    <ul>      <li><a href="/">Home</a></li>      <li><a href="/">Blog</a></li>
      <li><a href="/">Shop</a></li>    </ul>  </nav></header>
<!--page content-->
</body>

When used in an individual article, the header might include the article title, author, and the publication date, as shown here:

<article>  <header>    <h1>More about WOFF</h1>    <p>by Jennifer Robbins, <time datetime="2017-11-11">November 11, 2017</time></p>  </header>  <!-- article content here -->
</article>

Footers

The footer element is used to indicate the type of information that typically comes at the end of a page or an article, such as its author, copyright information, related documents, or navigation. The footer element may apply to the entire document, or it could be associated with a particular section or article. If the footer is contained directly within the body element, either before or after all the other body content, then it applies to the entire page or application. If it is contained in a sectioning element (section, article, nav, or aside), it is parsed as the footer for just that section. Note that although it is called “footer,” there is no requirement that it appear last in the document or sectioning element. It could also appear at or near the beginning if that makes sense.

In this simple example, we see the typical information listed at the bottom of an article marked up as a footer:

<article>  <header>    <h1>More about WOFF</h1>    <p>by Jennifer Robbins, <time datetime="2017-11-11">November 11, 2017</time></p>  </header>  <!-- article content here -->
  <footer>    <p><small>Copyright &copy;2017 Jennifer Robbins.</small></p>    <nav>      <ul>        <li><a href="/">Previous</a></li>        <li><a href="/">Next</a></li>      </ul>    </nav>  </footer></article>

Sections and Articles

Long documents are easier to use when they are divided into smaller parts. For example, books are divided into chapters, and newspapers have sections for local news, sports, comics, and so on. To divide long web documents into thematic sections, use the aptly named section element. Sections typically include a heading (inside the section element) plus content that has a meaningful reason to be grouped together.

The section element has a broad range of uses, from dividing a whole page into major sections or identifying thematic sections within a single article. In the following example, a document with information about typography resources has been divided into two sections based on resource type:

<section>  <h2>Typography Books</h2>  <ul>     <li>…</li>  </ul></section>


<section>  <h2>Online Tutorials</h2>  <p>These are the best tutorials on the web.</p>  <ul>    <li>…</li>  </ul></section>

Use the article element for self-contained works that could stand alone or be reused in a different context (such as syndication). It is useful for magazine or newspaper articles, blog posts, comments, or other items that could be extracted for external use. You can think of it as a specialized section element that answers “yes” to the question “Could this appear on another site and make sense?”

A long article could be broken into a number of sections, as shown here:

<article>  <h1>Get to Know Helvetica</h1>  <section>    <h2>History of Helvetica</h2>    <p>…</p>  </section>


  <section>    <h2>Helvetica Today</h2>    <p>…</p>  </section></article>

Conversely, a section in a web document might be composed of a number of articles:

<section id="essays">  <article>    <h1>A Fresh Look at Futura</h1>    <p>…</p>  </article>


  <article>    <h1>Getting Personal with Humanist</h1>    <p>…</p>  </article></section>

The section and article elements are easily confused, particularly because it is possible to nest one in the other and vice versa. Keep in mind that if the content is self-contained and could appear outside the current context, it is best marked up as an article.

Aside (Sidebars)

The aside element identifies content that is separate from, but tangentially related to, the surrounding content. In print, its equivalent is a sidebar, but it couldn’t be called “sidebar” because putting something on the “side” is a presentational description, not semantic. Nonetheless, a sidebar is a good mental model for using the aside element. aside can be used for pull quotes, background information, lists of links, callouts, or anything else that might be associated with (but not critical to) a document.

In this example, an aside element is used for a list of links related to the main article:

<h1>Web Typography</h1><p>Back in 1997, there were competing font formats and tools for making them…</p><p>We now have a number of methods for using beautiful fonts on web pages…</p><aside>  <h2>Web Font Resources</h2>  <ul>    <li><a href="http://typekit.com/">Typekit</a></li>    <li><a href="http://fonts.google.com">Google Fonts</a></li>  </ul></aside>

The aside element has no default rendering, so you will need to make it a block element and adjust its appearance and layout with style sheet rules.

Navigation

The nav element gives developers a semantic way to identify navigation for a site. Earlier in this chapter, we saw an unordered list that might be used as the top-level navigation for a font catalog site. Wrapping that list in a nav element makes its purpose explicitly clear:

<nav>  <ul>    <li><a href="/">Serif</a></li>    <li><a href="/">Sans-serif</a></li>    <li><a href="/">Script</a></li>    <li><a href="/">Display</a></li>    <li><a href="/">Dingbats</a></li>  </ul></nav>

Not all lists of links should be wrapped in nav tags, however. The spec makes it clear that nav should be used for links that provide primary navigation around a site or a lengthy section or article. The nav element may be especially helpful from an accessibility perspective.

Addresses

Last, and well, least, is the address element that is used to create an area for contact information for the author or maintainer of the document. It is generally placed at the end of the document or in a section or article within a document. An address would be right at home in a footer element. It is important to note that the address element should not be used for any old address on a page, such as mailing addresses. It is intended specifically for author contact information (although that could potentially be a mailing address). Following is an example of its intended use:

<address>Contributed by <a href="../authors/robbins/">Jennifer Robbins</a>, <a href="http://www.oreilly.com/">O'Reilly Media</a> </address> 

The Inline Element Roundup

Now that we’ve identified the larger chunks of content, we can provide semantic meaning to phrases within the chunks by using what the HTML5 specification calls text-level semantic elements. On the street, you are likely to hear them called inline elements because they display in the flow of text by default and do not cause any line breaks. That’s also how they were referred to in HTML versions prior to HTML5.

Text-Level (Inline) Elements

Despite all the types of information you could add to a document, there are only a couple dozen text-level semantic elements. Table 5-1 lists all of them.

a

abbr

b

bdi

bdo

br

cite

code

data

del

dfn

em

i

ins

kbd

mark

q

ruby, rt, rp

s

samp

small

span

strong

sub

sup

time

u

var

wbr

Although it may be handy seeing all of the text-level elements listed together in a table, they certainly deserve more detailed explanations.

Emphasized text

Use the em element to indicate which part of a sentence should be stressed or emphasized. The placement of em elements affects how a sentence’s meaning is interpreted. Consider the following sentences that are identical, except for which words are stressed:

<p><em>Arlo</em> is very smart.</p><p>Arlo is <em>very</em> smart.</p>

The first sentence indicates who is very smart. The second example is about how smart he is. Notice that the em element has an effect on the meaning of the sentence.

Emphasized text (em) elements nearly always display in italics by default (Figure 5-9), but of course you can make them display any way you like with a style sheet. Screen readers may use a different tone of voice to convey stressed content, which is why you should use an em element only when it makes sense semantically, not just to achieve italic text.

Important text

The strong element indicates that a word or phrase is important, serious, or urgent. In the following example, the strong element identifies the portion of instructions that requires extra attention. The strong element does not change the meaning of the sentence; it merely draws attention to the important parts:

<p>When returning the car, <strong>drop the keys in the red box by the front desk</strong>.</p>

Visual browsers typically display strong text elements in bold text by default. Screen readers may use a distinct tone of voice for important content, so mark text as strong only when it makes sense semantically, not just to make text bold.

The following is a brief example of our em and strong text examples. Figure 5-9 should hold no surprises.

Elements originally named for their presentational properties

As long as we’re talking about bold and italic text, let’s see what the old b and i elements are up to now. The elements b, i, u, s, and small were introduced in the old days of the web as a way to provide typesetting instructions (bold, italic, underline, strike-through, and smaller text, respectively). Despite their original presentational purposes, these elements have been included in HTML5 and given updated, semantic definitions based on patterns of how they’ve been used. Browsers still render them by default as you’d expect (Figure 5-10). However, if a type style change is all you’re after, using a style sheet rule is the appropriate solution. Save these for when they are semantically appropriate.

Let’s look at these elements and their correct usage, as well as the style sheet alternatives.

b

Keywords, product names, and other phrases that need to stand out from the surrounding text without conveying added importance or emphasis (see Note). [Old definition: Bold]

CSS Property: For bold text, use font-weight. Example: font-weight: bold;

Example: <p>The slabs at the ends of letter strokes are called <b>serifs</b>.</p>

i

Indicates text that is in a different voice or mood than the surrounding text, such as a phrase from another language, a technical term, or a thought. [Old definition: Italic]

CSS Property: For italic text, use font-style. Example: font-style: italic;

Example: <p>Simply change the font and <i>Voila!</i>, a new personality!</p>

s

Indicates text that is incorrect. [Old definition: Strike-through text]

CSS Property: To draw a line through a selection of text, use text-decoration. Example: text-decoration: line-through

Example: <p>Scala Sans was designed by <s>Eric Gill</s> Martin Majoor.</p>

u

There are a few instances when underlining has semantic significance, such as underlining a formal name in Chinese or indicating a misspelled word after a spell check, such as the misspelled “Helvitica” in the following example. Note that underlined text is easily confused with a link and should generally be avoided except for a few niche cases. [Old definition: Underline]

CSS Property: For underlined text, use text-decoration. Example: text-decoration: underline

Example: <p>New York subway signage is set in <u>Helviteca</u>.</p>

small

Indicates an addendum or side note to the main text, such as the legal “small print” at the bottom of a document. [Old definition: Renders in font smaller than the surrounding text]

CSS Property: To make text smaller, use font-size. Example: font-size: 80%

Example: <p><small>(This font is free for personal and commercial use.)</small></p>

Short quotations

Use the quotation (q) element to mark up short quotations, such as “To be or not to be,” in the flow of text, as shown in this example (Figure 5-11):

Matthew Carter says, <q>Our alphabet hasn't changed in eons.</q>

According to the HTML spec, browsers should add quotation marks around q elements automatically, so you don’t need to include them in the source document. Some browsers, like Firefox, render curly quotes, which is preferable. Others (Safari and Chrome, which I used for my examples) render them as straight quotes as shown in the figure.

<q><i>Je ne sais pas.</i></q>

<q><i>Je ne sais pas.</q></i>

Abbreviations and acronyms

Marking up acronyms and abbreviations with the abbr element provides useful information for search engines, screen readers, and other devices. Abbreviations are shortened versions of a word ending in a period (“Conn.” for “Connecticut,” for example). Acronyms are abbreviations formed by the first letters of the words in a phrase (such as NASA or USA). The title attribute provides the long version of the shortened term, as shown in this example:

<abbr title="Points">pts.</abbr> <abbr title="American Type Founders">ATF</abbr> 

Citations

The cite element is used to identify a reference to another document, such as a book, magazine, article title, and so on. Citations are typically rendered in italic text by default. Here’s an example:

<p>Passages of this article were inspired by <cite>The Complete Manual of Typography</cite> by James Felici.</p>

Defining terms

It is common to point out the first and defining instance of a word in a document in some fashion. In this book, defining terms are set in blue text. In HTML, you can identify them with the dfn element and format them visually using style sheets.

<p><dfn>Script typefaces</dfn> are based on handwriting.</p>

Program code elements

A number of inline elements are used for describing the parts of technical documents, such as code (code), variables (var), program samples (samp), and user-entered keyboard strokes (kbd). For me, it’s a quaint reminder of HTML’s origins in the scientific world (Tim Berners-Lee developed HTML to share documents at the CERN particle physics lab in 1989).

Code, sample, and keyboard elements typically render in a constant-width (also called monospace) font such as Courier by default. Variables usually render in italics.

Subscript and superscript

The subscript (sub) and superscript (sup) elements cause the selected text to display in a smaller size, positioned slightly below (sub) or above (sup) the baseline. These elements may be helpful for indicating chemical formulas or mathematical equations.

Figure 5-12 shows how these examples of subscript and superscript typically render in a browser.

 <p>H<sub>2</sub>0</p>  <p>E=MC<sup>2</sup></p>

Highlighted text

The mark element indicates a word that may be considered especially relevant to the reader. One might use it to dynamically highlight a search term in a page of results, to manually call attention to a passage of text, or to indicate the current page in a series. Some designers (and browsers) give marked text a light colored background as though it were marked with a highlighter marker, as shown in Figure 5-13.

<p> ... PART I. ADMINISTRATION OF THE GOVERNMENT. TITLE IX.TAXATION. CHAPTER 65C. MASS. <mark>ESTATE TAX</mark>. Chapter 65C: Sect. 2. Computation of <mark>estate tax</mark>.</p> 

Dates and times

When we look at the phrase “noon on November 4,” we know that it is a date and a time. But the context might not be so obvious to a computer program. The time element allows us to mark up dates and times in a way that is comfortable for a human to read, but also encoded in a standardized way that computers can use. The content of the element presents the information to people, and the datetime attribute presents the same information in a machine-readable way.

The time element indicates dates, times, or date-time combos. It might be used to pass the date and time information to an application, such as saving an event to a personal calendar. It might be used by search engines to find the most recently published articles. Or it could be used to restyle time information into an alternate format (e.g., changing 18:00 to 6 p.m.).

The datetime attribute specifies the date and/or time information in a standardized time format illustrated in Figure 5-14. The full time format begins with the date (year–month–day). The time section begins with a letter “T” and lists hours (on the 24-hour clock), minutes, seconds (optional), and milliseconds (also optional). Finally, the time zone is indicated by the number of hours behind (-) or ahead (+) of Greenwich Mean Time (GMT). For example, “-05:00” indicates the Eastern Standard time zone, which is five hours behind GMT. When identifying dates and times alone, you can omit the other sections.

Here are a few examples of valid values for datetime:

• Time only: 9:30 p.m.

  <time datetime="21:30">9:30p.m.</time>

• Date only: June 19, 2016

  <time datetime="2016-06-19">June 19, 2016</time>

• Date and time: Sept. 5, 1970, 1:11a.m.

  <time datetime="1970-09-05T01:11:00">Sept. 5, 1970, 1:11a.m.</time>

• Date and time, with time zone information: 8:00am on July 19, 2015, in Providence, RI

  <time datetime="2015-07-19T08:00:00-05:00">July 19, 2015, 8am, Providence RI</time>

  Note

  You can also use the time element without the datetime attribute, but its content must be a valid date/time string:

  <time>2016-06-19</time>

  Further Reading

  For more information on the intricate ins and outs of specifying dates and times, with examples, check out the time element entry in the HTML5 specification: www.w3.org/TR/2014/REC-html5-20141028/text-level-semantics.html#the-time-element.

Machine-readable information

The data element is another tool for helping computers make sense of content. It can be used for all sorts of data, including dates, times, measurements, weights, microdata, and so on. The required value attribute provides the machine-readable information. Here are a couple of examples:

<data value="12">Twelve</data><data value="978-1-449-39319-9">CSS: The Definitive Guide</data>

I’m not going to go into more detail on the data element, because as a beginner, you are unlikely to be dealing with machine-readable data quite yet. But it is interesting to see how markup can be used to provide usable information to computer programs and scripts as well as to your fellow humans.

Inserted and deleted text

The ins and del elements are used to mark up edits indicating parts of a document that have been inserted or deleted (respectively). These elements rely on style rules for presentation (i.e., there is no dependable browser default). Both the ins and del elements can contain either inline or block elements, depending on what type of content they contain:

Chief Executive Officer: <del title="retired">Peter Pan</del><ins>Pippi Longstocking</ins>

Adding Breaks

Line breaks

Occasionally, you may need to add a line break within the flow of text. We’ve seen how browsers ignore line breaks in the source document, so we need a specific directive to tell the browser to “add a line break here.”

The inline line break element (br) does exactly that. The br element could be used to break up lines of addresses or poetry. It is an empty element, which means it does not have content. Just add the br element in the flow of text where you want a break to occur, as shown here and in Figure 5-15:

<p>So much depends <br>upon <br><br>a red wheel <br>barrow</p>

Unfortunately, the br element is easily abused. Be careful that you aren’t using br elements to force breaks into text that really ought to be a list. For example, don’t do this:

<p>Times<br>Georgia<br>Garamond </p>

If it’s a list, use the semantically correct unordered list element instead, and turn off the bullets with style sheets:

<ul>  <li>Times</li>  <li>Georgia</li>  <li>Garamond</li></ul>

Word breaks

The word break (wbr) element lets you mark the place where a word should break (a “line break opportunity” according to the spec) should there not be enough room for the whole word (Figure 5-16). It takes some of the guesswork away from the browser and allows authors to control the best spot for the word to be split over two lines. If there is enough room, the word stays in one piece. Without word breaks, the word stays together, and if there is not enough room, the whole word wraps to the next line. Note that the browser does not add a hyphen when the word breaks over two lines. The wbr behaves as though it were a character space in the middle of the word:

<p>The biggest word you've ever heard and this is how it goes: <em>supercali<wbr>fragilistic<wbr>expialidocious</em>!</p>

You’ve been introduced to 32 new elements since your last exercise. I’d say it’s time to give some of the inline elements a try in Exercise 5-2.

b   br   cite    dfn   em 

i   q    small   time 

<article> <header><p>posted by BGB, November 15, 2016</p></header> 
<h2>Low and Slow</h2><p>This week I am extremely excited about a new cooking technique called sous vide. In sous vide cooking, you submerge the food (usually vacuum-sealed in plastic) into a water bath that is precisely set to the target temperature you want the food to be cooked to. In his book, Cooking for Geeks, Jeff Potter describes it as ultra-low-temperature poaching.</p><p>Next month, we will be serving Sous Vide Salmon with Dill Hollandaise. To reserve a seat at the chef table, contact us before November 30.</p> 
<p>blackgoose@example.com
555-336-1800</p> <p>Warning: Sous vide cooked salmon is not pasteurized. Avoid it if you are pregnant or have immunity issues.</p></article>

Generic Elements (div and span)

What if none of the elements we’ve talked about so far accurately describes your content? After all, there are endless types of information in the world, but as you’ve seen, not all that many semantic elements. Fortunately, HTML provides two generic elements that can be customized to describe your content perfectly. The div element indicates a division of content, and span indicates a word or phrase for which no text-level element currently exists. The generic elements are given meaning and context with the id and class attributes, which we’ll discuss in a moment.

The div and span elements have no inherent presentation qualities of their own, but you can use style sheets to format them however you like. In fact, generic elements are a primary tool in standards-based web design because they enable authors to accurately describe content and offer plenty of “hooks” for adding style rules. They also allow elements on the page to be accessed and manipulated by JavaScript.

We’re going to spend a little time on div and span elements, as well as the id and class attributes, to learn how authors use them to structure content.

Divide It Up with a div

Use the div element to create a logical grouping of content or elements on the page. It indicates that they belong together in a conceptual unit or should be treated as a unit by CSS or JavaScript. By marking related content as a div and giving it a unique id or indicating that it is part of a class, you give context to the elements in the grouping. Let’s look at a few examples of div elements.

In this example, a div element is used as a container to group an image and two paragraphs into a product “listing”:

<div class="listing">  <img src="images/felici-cover.gif" alt="">  <p><cite>The Complete Manual of Typography</cite>, James Felici</p>  <p>A combination of type history and examples of good and bad type design.</p></div> 

By putting those elements in a div, I’ve made it clear that they are conceptually related. It also allows me to style p elements within listings differently than other p elements in the document.

Here is another common use of a div used to break a page into sections for layout purposes. In this example, a heading and several paragraphs are enclosed in a div and identified as the “news” division:

<div id="news">  <h1>New This Week</h1>  <p>We've been working on...</p>  <p>And last but not least,... </p></div>

Now I have a custom element that I’ve given the name “news.” You might be thinking, “Hey Jen, couldn’t you use a section element for that?” You could! In fact, authors may turn to generic divs less often now that we have better semantic sectioning elements in HTML5.

Define a Phrase with span

A span offers the same benefits as the div element, except it is used for phrase elements and does not introduce line breaks. Because spans are inline elements, they may contain only text and other inline elements (in other words, you cannot put headings, lists, content-grouping elements, and so on, in a span). Let’s get right to some examples.

There is no telephone element, but we can use a span to give meaning to telephone numbers. In this example, each telephone number is marked up as a span and classified as “tel”:

<ul>  <li>John: <span class="tel">999.8282</span></li>  <li>Paul: <span class="tel">888.4889</span></li>  <li>George: <span class="tel">888.1628</span></li>  <li>Ringo: <span class="tel">999.3220</span></li></ul>

You can see how the classified spans add meaning to what otherwise might be a random string of digits. As a bonus, the span element enables us to apply the same style to phone numbers throughout the site (for example, ensuring line breaks never happen within them, using a CSS white-space: nowrap declaration). It makes the information recognizable not only to humans but also to computer programs that know that “tel” is telephone number information. In fact, some values—including “tel”—have been standardized in a markup system known as Microformats that makes web content more useful to software (see the upcoming sidebar “Structured Data in a Nutshell”).

id and class Attributes

In the previous examples, we saw the id and class attributes used to provide context to generic div and span elements. id and class have different purposes, however, and it’s important to know the difference.

Identification with id

The id attribute is used to assign a unique identifier to an element in the document. In other words, the value of id must be used only once in the document. This makes it useful for assigning a name to a particular element, as though it were a piece of data. See the sidebar “id and class Values” for information on providing values for the id attribute.

This example uses the books’ ISBNs (International Standard Book Numbers) to uniquely identify each listing. No two book listings may share the same id.

<div id="ISBN0321127307">  <img src="felici-cover.gif" alt="">  <p><cite>The Complete Manual of Typography</cite>, James Felici</p>  <p>A combination of type history and examples of good and bad type.  </p></div> 


<div id="ISBN0881792063">  <img src="bringhurst-cover.gif" alt="">  <p><cite>The Elements of Typographic Style</cite>, Robert Bringhurst   </p>  <p>This lovely, well-written book is concerned foremost with creating beautiful typography.</p></div>

Web authors also use id when identifying the various sections of a page. In the following example, there may not be more than one element with the id of “links” or “news” in the document:

<section id="news">  <!-- news items here -->
</section>


<aside id="links">  <!-- list of links here -->
</aside>

Classification with class

The class attribute classifies elements into conceptual groups; therefore, unlike the id attribute, a class name may be shared by multiple elements. By making elements part of the same class, you can apply styles to all of the labeled elements at once with a single style rule or manipulate them all with a script. Let’s start by classifying some elements in the earlier book example. In this first example, I’ve added class attributes to classify each div as a “listing” and to classify paragraphs as “descriptions”:

<div id="ISBN0321127307" class="listing">  <header>  <img src="felici-cover.gif" alt="">  <p><cite>The Complete Manual of Typography</cite>, James Felici</p>  </header>  <p class="description">A combination of type history and examples of good and bad type.</p></div> 


<div id="ISBN0881792063" class="listing">  <header>  <img src="bringhurst-cover.gif" alt="">  <p><cite>The Elements of Typographic Style</cite>, Robert Bringhurst   </p>  </header>  <p class="description">This lovely, well-written book is concerned foremost with creating beautiful typography.</p></div>

Notice how the same element may have both a class and an id. It is also possible for elements to belong to multiple classes. When there is a list of class values, simply separate them with character spaces. In this example, I’ve classified each div as a “book” to set them apart from possible “cd” or “dvd” listings elsewhere in the document:

<div id="ISBN0321127307" class="listing book">  <img src="felici-cover.gif" alt="CMT cover">  <p><cite>The Complete Manual of Typography</cite>, James Felici</p>  <p class="description">A combination of type history and examples of good and bad type.</p></div> 


<div id="ISBN0881792063" class="listing book">  <img src="bringhurst-cover.gif" alt="ETS cover">  <p><cite>The Elements of Typographic Style</cite>, Robert Bringhurst   </p>  <p class="description">This lovely, well-written book is concerned   foremost with creating beautiful typography.</p></div>

Identify and Classify All Elements

The id and class attributes are not limited to just div and span—they are two of the global attributes (see the “Global Attributes” sidebar) in HTML, which means you may use them with all HTML elements. For example, you could identify an ordered list as “directions” instead of wrapping it in a div:

<ol id="directions">  <li>...</li>  <li>...</li>  <li>...</li></ol>

This should have given you a good introduction to how to use the class and id attributes to add meaning and organization to documents. We’ll work with them even more in the style sheet chapters in Part III. The sidebar “Structured Data in a Nutshell” discusses more advanced ways of adding meaning and machine-readable data to documents.

<div class="h-card">  <p class="p-name">Cindy Sherman</p>  <p class="p-tel">555.999-2456</p></div>

<div itemscope itemtype="http://schema.org/Person">  <p itemprop="name">Cindy Sherman</p>  <p itemprop="telephone">555.999-2456</p></div>

<div vocab="http://schema.org" typeof="Person">  <p property="name">Cindy Sherman</p>  <p property="telephone">555.999-2456</p></div>

<script type="application/ld+json">{  "@context": "http://schema.org/",  "@type": "Person",  "name": "Cindy Sherman"  "telephone": "555.999-2456"}</script>

Improving Accessibility with ARIA

As web designers, we must always consider the experience of users with assistive technologies for navigating pages and interacting with web applications. Your users may be listening to the content on the page read aloud by a screen reader and using keyboards, joysticks, voice commands, or other non-mouse input devices to navigate through the page.

Many HTML elements are plainly understood when you look at (or read) only the HTML source. Elements like the title, headings, lists, images, and tables have implicit meanings in the context of a page, but generic elements like div and span lack the semantics necessary to be interpreted by an assistive device. In rich web applications, especially those that rely heavily on JavaScript and AJAX (see Note), the markup alone does not provide enough clues as to how elements are being used or whether a form control is currently selected, required, or in some other state.

Fortunately, we have ARIA (Accessible Rich Internet Applications), a standardized set of attributes for making pages easier to navigate and interactive features easier to use. The specification was created and is maintained by a Working Group of the Web Accessibility Initiative (WAI), which is why you also hear it referred to as WAI-ARIA. ARIA defines roles, states, and properties that developers can add to markup and scripts to provide richer semantic information.

Roles

Roles describe an element’s function or purpose in the context of the document. Some roles include alert, button, dialog, slider, and menubar, to name only a few. For example, as we saw earlier, you can turn an unordered list into a tabbed menu of options using style sheets, but what if you can’t see that it is styled that way? Adding role="toolbar" to the list makes its purpose clear:

<ul id="tabs" role="toolbar">  <li>A-G</li>  <li>H-O</li>  <li>P-T</li>  <li>U-Z</li></ul>

Here’s another example that reveals that the “status” div is used as an alert message:

<div id="status" role="alert">You are no longer connected to the server.</div>

Some roles describe “landmarks” that help readers find their way through the document, such as navigation, banner, contentinfo, complementary, and main. You may notice that some of these sound similar to the page-structuring elements that were added in HTML5, and that’s no coincidence. One of the benefits of having improved semantic section elements is that they can be used as landmarks, replacing <div id="main" role="main"> with main.

Most current browsers already recognize the implicit roles of the new elements, but some developers explicitly add ARIA roles until all browsers comply. The sectioning elements pair with the ARIA landmark roles in the following way:

<nav role="navigation">

<header role="banner"> (see Note)

<main role="main">

<aside role="complementary">

<footer role="contentinfo">

States and Properties

ARIA also defines a long list of states and properties that apply to interactive elements such as form widgets and dynamic content. States and properties are indicated with attributes prefixed with aria-, such as aria-disabled, aria-describedby, and many more.

The difference between a state and property is subtle. For properties, the value of the attribute is more likely to be stable, such as aria-labelledby, which associates labels with their respective form controls, or aria-haspopup, which indicates the element has a related pop-up menu. States have values that are more likely to be changed as the user interacts with the element, such as aria-selected.

For Further Reading

Obviously, this is not enough ARIA coaching to allow you to start confidently using it today, but it should give you a good feel for how it works and its potential value. When you are ready to dig in and take your skills to a professional level, here is some recommended reading:

The WAI-ARIA Working Draft (www.w3.org/TR/wai-aria-1.1/)

This is the current Working Draft of the specification as of this writing.

ARIA in HTML (www.w3.org/TR/html-aria/)

This W3C Working Draft helps developers use ARIA attributes with HTML correctly. It features a great list of every HTML element, whether it has an implicit role (in which ARIA should not be used), and what roles, states, and properties apply.

ARIA Resources at MDN Web Docs (developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA)

This site features lots of links to ARIA-related and up-to-date resources. It is a good starting point for exploration.

HTML5 Accessibility (www.html5accessibility.com)

This site tests which new HTML5 features are accessibly supported by major browsers.

Character Escapes

There’s just one more text-related topic before we close out this chapter. The section title makes it sound like someone left the gate open and all the characters got out. The real meaning is more mundane, albeit useful to know.

You already know that as a browser parses an HTML document, when it runs into a < symbol, it interprets it as the beginning of a tag. But what if you just need a less-than symbol in your text? Characters that might be misinterpreted as code need to be escaped in the source document. Escaping means that instead of typing in the character itself, you represent it by its numeric or named character entity reference. When the browser sees the character reference, it substitutes the proper character in that spot when the page is displayed.

There are two ways of referring to (escaping) a specific character:

• Using a predefined abbreviated name for the character (called a named entity; see Note).

  Note

  HTML defines hundreds of named entities as part of the markup language, which is to say you can’t make up your own entity.

• Using an assigned numeric value that corresponds to its position in a coded character set (numeric entity). Numeric values may be in decimal or hexadecimal format.

All character references begin with an & (ampersand) and end with a ; (semicolon).

An example should make this clear. I’d like to use a less-than symbol in my text, so I must use the named entity (&lt;) or its numeric equivalent (&#060;) where I want the symbol to appear (Figure 5-17):

<p>3 tsp. &lt; 3 Tsp.</p>

or:

<p>3 tsp. &#060; 3 Tsp.</p>

When to Escape Characters

There are a few instances in which you may need or want to use a character reference.

HTML syntax characters

The <, >, &, ", and ' characters have special syntax meaning in HTML, and may be misinterpreted as code. Therefore, the W3C recommends that you escape <, >, and & characters in content. If attribute values contain single or double quotes, escaping the quote characters in the values is advised. Quote marks are fine in the content and do not need to be escaped. (See Table 5-2.)

<

<

<

>

>

>

"

"

"

'

'

'

&

&

&

Invisible or ambiguous characters

Some characters have no graphic display and are difficult to see in the markup (Table 5-3). These include the non-breaking space (&nbsp;), which is used to ensure that a line doesn’t break between two words. So, for instance, if I mark up my name like this:

Jennifer Robbins

I can be sure that my first and last names will always stay together on a line. Another use for non-breaking spaces is to separate digits in a long number, such as 32 000 000.

Zero-width space can be placed in languages that do not use spaces between words to indicate where the line should break. A zero-width joiner is a non-printing space that causes neighboring characters to display in their connected forms (common in Arabic and Indic languages). Zero-width non-joiners prevent neighboring characters from joining to form ligatures or other connected forms.

 

 

 

 

 

 

 

 

 

​

​

‌

‌

‌

‍

‍

‍

Input limitations

If your keyboard or editing software does not include the character you need (or if you simply can’t find it), you can use a character entity to make sure you get the character you want. The W3C doesn’t endorse this practice, so use the proper character in your source if you are able. Table 5-4 lists some special characters that may be less straightforward to type into the source.

‘

‘

‘

’

’

’

“

“

“

”

”

”

…

…

…

© 

©

©

® 

®

®

™

™

…

£ 

£

£

¥ 

¥

¥

€

€

€

–

–

–

—

—

—

A complete list of HTML named entities and their Unicode code-points can be found as part of the HTML5 specification at www.w3.org/TR/html5/syntax.html#named-character-references. For a more user-friendly listing of named and numerical entities, I recommend this archived page at the Web Standards Project: www.webstandards.org/learn/reference/charts/entities.

Putting It All Together

So far, you’ve learned how to mark up elements, and you’ve met all of the HTML elements for adding structure and meaning to text content. Now it’s just a matter of practice. Exercise 5-3 gives you an opportunity to try out everything we’ve covered so far: document structure elements, grouping (block) elements, phrasing (inline) elements, sectioning elements, and character entities. Have fun!

The Black Goose Bistro News

Home

Menu

News

Contact

Summer Menu Items

posted by BGB, June 18, 2017

Our chef has been busy putting together the perfect menu for the summer months. Stop by to try these appetizers and main courses while the days are still long.

Appetizers

Black bean purses

Spicy black bean and a blend of Mexican cheeses wrapped in sheets of phyllo and baked until golden. $3.95

Southwestern napoleons with lump crab -- new item!

Layers of light lump crab meat, bean and corn salsa, and our handmade flour tortillas. $7.95

Main courses

Shrimp sate kebabs with peanut sauce

Skewers of shrimp marinated in lemongrass, garlic, and fish sauce then grilled to perfection. Served with spicy peanut sauce and jasmine rice. $12.95

Jerk rotisserie chicken with fried plantains -- new item!

Tender chicken slow-roasted on the rotisserie, flavored with spicy and fragrant jerk sauce and served with fried plantains and fresh mango. $12.95

Low and Slow

posted by BGB, November 15, 2016

<p>This week I am <em>extremely</em> excited about a new cooking technique called <dfn><i>sous vide</i></dfn>. In <i>sous vide</i> cooking, you submerge the food (usually vacuum-sealed in plastic) into a water bath that is precisely set to the target temperature you want the food to be cooked to. In his book, <cite>Cooking for Geeks</cite>, Jeff Potter describes it as <q>ultra-low-temperature poaching.</q></p>

<p>Next month, we will be serving <b><i>Sous Vide</i> Salmon with Dill Hollandaise</b>. To reserve a seat at the chef table, contact us before <time datetime="20161130">November 30</time>.</p>

Location: Baker’s Corner, Seekonk, MA

Hours: Tuesday to Saturday, 11am to 11pm

All content copyright 2017, Black Goose Bistro and Jennifer Robbins

Test Yourself

Were you paying attention? Here is a rapid-fire set of questions to find out. Find the answers in Appendix A.

1. Add the markup to insert a thematic break between these paragraphs:

   <p>People who know me know that I love to cook.</p>

   <p>I've created this site to share some of my favorite recipes.</p> 

2. What’s the difference between a blockquote and a q element?
3. Which element displays whitespace exactly as it is typed into the source document?
4. What is the difference between a ul and an ol element?
5. How do you remove the bullets from an unordered list? (Be general, not specific.)
6. What element would you use to mark up “W3C” and provide its full name (World Wide Web Consortium)? Can you write out the complete markup?
7. What is the difference between dl and dt?
8. What is the difference between id and class?
9. What is the difference between an article and a section?

Element Review: Text Elements

The global attributes apply to all text elements. Additional attributes are listed under their respective elements.

address

article

aside

footer

header

nav

section

h1...h6

blockquote

cite

div

figure

figcaption

hr

main

p

pre

dd

dl

dt

li

value

ol

reversed

start

ul

br

wbr

abbr

b

bdi 

bdo

cite

code

data

del

cite

datetime

dfn

em

i

ins

cite

datetime

kbd

mark

q

cite

ruby

rp

rt

s

samp

small

span

strong

sub

sup

time

datetime

pubdate

u

6. Adding Links

6

Adding Links

If you’re creating a page for the web, chances are you’ll want to link to other web pages and resources, whether on your own site or someone else’s. Linking, after all, is what the web is all about. In this chapter, we’ll look at the markup that makes links work—links to other sites, to your own site, and within a page. There is one element that makes linking possible: the anchor (a).

<a>…</a>

Anchor element (hypertext link)

To make a selection of text a link, simply wrap it in opening and closing <a>...</a> tags and use the href attribute to provide the URL of the target page. The content of the anchor element becomes the hypertext link. Here is an example that creates a link to the O’Reilly Media site:

<a href="http://www.oreilly.com">Go to the O'Reilly Media site</a>

To make an image a link, simply put the img element in the anchor element:

<a href="http://www.oreilly.com"><img src="tarsierlogo.gif" alt="O'Reilly Media site"></a>

By the way, you can put any HTML content element in an anchor to make it a link, not just images.

Nearly all graphical browsers display linked text as blue and underlined by default. Some older browsers put a blue border around linked images, but most current ones do not. Visited links generally display in purple. Users can change these colors in their browser preferences, and, of course, you can change the appearance of links for your sites using style sheets. I’ll show you how in Chapter 13, Colors and Backgrounds.

When a user clicks or taps the linked text or image, the page you specify in the anchor element loads in the browser window. The linked image markup sample shown previously might look like Figure 6-1.

The href Attribute

<a href="url">linked content</a>

You’ll need to tell the browser which document to link to, right? The href (hypertext reference) attribute provides the address of the page or resource (its URL) to the browser. The URL must always appear in quotation marks. Most of the time you’ll point to other HTML documents; however, you can also point to other web resources, such as images, audio, and video files.

Because there’s not much to slapping anchor tags around some content, the real trick to linking comes in getting the URL correct. There are two ways to specify the URL:

Absolute URLs

Absolute URLs provide the full URL for the document, including the protocol (http:// or https://), the domain name, and the pathname as necessary. You need to use an absolute URL when pointing to a document out on the web (i.e., not on your own server):

href="http://www.oreilly.com/"

Sometimes, when the page you’re linking to has a long URL pathname, the link can end up looking pretty confusing (Figure 6-2). Just keep in mind that the structure is still a simple container element with one attribute. Don’t let the long pathname intimidate you.

Relative URLs

Relative URLs describe the pathname to a file relative to the current document. Relative URLs can be used when you are linking to another document on your own site (i.e., on the same server). It doesn’t require the protocol or domain name—just the pathname:

href="recipes/index.html"

In this chapter, we’ll add links using absolute and relative URLs to my cooking website, Jen’s Kitchen (see Figure 6-3). Absolute URLs are easy, so let’s get them out of the way first.

Linking to Pages on the Web

Many times, you’ll want to create a link to a page that you’ve found on the web. This is known as an external link because it is going to a page outside of your own server or site. To make an external link, provide the absolute URL, beginning with http:// (the protocol). This tells the browser, “Go out on the web and get the following document.”

I want to add some external links to the Jen’s Kitchen home page (Figure 6-3). First, I’ll link the list item “The Food Network” to the www.foodnetwork.com site. I marked up the link text in an anchor element by adding opening and closing anchor tags. Notice that I’ve added the anchor tags inside the list item (li) element. That’s because only li elements are permitted to be children of a ul element; placing an a element directly inside the ul element would be invalid HTML.

<li><a>The Food Network</a></li>

Next, I add the href attribute with the complete URL for the site:

<li><a href="http://www.foodnetwork.com">The Food Network</a></li>

And voilà! Now “The Food Network” appears as a link and takes my visitors to that site when they click or tap it. Give it a try in Exercise 6-1.

<ul>  <li><a href="http://www.foodnetwork.com/">The Food Network</a></li>  <li>Epicurious</li></ul>

Linking Within Your Own Site

A large portion of the linking you do is between pages of your own site: from the home page to section pages, from section pages to content pages, and so on. In these cases, you can use a relative URL—one that calls for a page on your own server.

Without “http://”, the browser looks on the current server for the linked document. A pathname, the notation used to point to a particular file or directory, (see Note) tells the browser where to find the file. Web pathnames follow the Unix convention of separating directory and filenames with forward slashes (/). A relative pathname describes how to get to the linked document starting from the location of the current document.

Relative pathnames can get a bit tricky. In my teaching experience, nothing stumps beginners like writing relative pathnames, so we’ll take it one step at a time. I recommend you do Exercises 6-2 through 6-8 as we go along.

All of the pathname examples in this section are based on the structure of the Jen’s Kitchen site shown in Figure 6-4. When you diagram the structure of the directories for a site, it generally ends up looking like an inverted tree with the root directory at the top of the hierarchy. For the Jen’s Kitchen site, the root directory is named jenskitchen. For another way to look at it, there is also a view of the directory and subdirectories as they appear in the Finder on my Mac.

Linking Within a Directory

The most straightforward relative URL points to another file within the same directory. When linking to a file in the same directory, you need to provide only the name of the file (its filename). When the URL is just a filename, the server looks in the current directory (that is, the directory that contains the document with the link) for the file.

In this example, I want to make a link from my home page (index.html) to a general information page (about.html). Both files are in the same directory (jenskitchen). So, from my home page, I can make a link to the information page by simply providing its filename in the URL (Figure 6-5):

<a href="about.html">About the site...</a>

Exercise 6-2 gives you a chance to mark up a simple link yourself.

<p>Back to the home page</p>

Linking to a Lower Directory

But what if the files aren’t in the same directory? You have to give the browser directions by including the pathname in the URL. Let’s see how this works.

Getting back to our example, my recipe files are stored in a subdirectory called recipes. I want to make a link from index.html to a file in the recipes directory called salmon.html. The pathname in the URL tells the browser to look in the current directory for a directory called recipes, and then look for the file salmon.html (Figure 6-6):

<li><a href="recipes/salmon.html">Garlic Salmon</a></li>

Have a try at linking to a file in a directory in Exercise 6-3.

<li>Tapenade (Olive Spread)</li>

Now let’s link down to the file called couscous.html, which is located in the pasta subdirectory. All we need to do is provide the directions through two subdirectories (recipes, then pasta) to couscous.html (Figure 6-7):

<li><a href="recipes/pasta/couscous.html">Couscous...</a></li>

Directories are separated by forward slashes. The resulting anchor tag tells the browser, “Look in the current directory for a directory called recipes. There you’ll find a directory called pasta, and in there is the file couscous.html.”

Now that we’ve done two directory levels, you should get the idea of how pathnames are assembled. This same method applies for relative pathnames that drill down through any number of directories. Just start with the name of the directory that is in the same location as the current file, and follow each directory name with a slash until you get to the linked filename.

<li>Linguine with Clam Sauce</li>

Linking to a Higher Directory

So far, so good, right? Now it gets more interesting. This time we’re going to go in the other direction and make a link from the salmon recipe page back to the home page, which is one directory level up.

In Unix, there is a pathname convention just for this purpose, the “dot-dot-slash” (../). When you begin a pathname with ../, it’s the same as telling the browser “back up one directory level” and then follow the path to the specified file. If you are familiar with browsing files on your desktop, it is helpful to know that a “../” has the same effect as clicking the Up button in Windows Explorer or the left-arrow button in the Finder on macOS.

Let’s start by making a link from salmon.html back to the home page (index.html). Because salmon.html is in the recipes subdirectory, we need to go back up to the jenskitchen directory to find index.html. This pathname tells the browser to “back up one level,” then look in that directory for index.html (Figure 6-8):

<p><a href="../index.html">[Back to home page]</a></p>

Note that the ../ stands in for the name of the higher directory, and we don’t need to write out jenskitchen in the pathname.

Try adding a dot-dot-slash pathname to a higher directory in Exercise 6-5.

<p>[Back to the home page]</p>

But how about linking back to the home page from couscous.html? Can you guess how you’d back your way out of two directory levels? Simple: just use the dot-dot-slash twice (Figure 6-9).

A link on the couscous.html page back to the home page (index.html) would look like this:

<p><a href="../../index.html">[Back to home page]</a></p>

The first ../ backs up to the recipes directory; the second ../ backs up to the top-level directory (jenskitchen), where index.html can be found. Again, there is no need to write out the directory names; the ../ does it all.

Now you try (Exercise 6-6).

<p>[Back to the home page]</p>

Linking with Site Root Relative Pathnames

All sites have a root directory, the directory that contains all the directories and files for the site. So far, all of the pathnames we’ve looked at are relative to the document with the link. Another way to write a relative pathname is to start at the root directory and list the subdirectory names to the file you want to link to. This type of pathname is known as site root relative.

In the Unix pathname convention, a forward slash (/) at the start of the pathname indicates that the path begins at the root directory. The site root relative pathname in the following link reads, “Go to the very top-level directory for this site, open the recipes directory, and then find the salmon.html file” (Figure 6-10):

<a href="/recipes/salmon.html">Garlic Salmon</a>

Note that you don’t need to (and you shouldn’t) write the name of the root directory (jenskitchen) in the path—the forward slash (/) at the beginning represents the top-level directory in the pathname. From there, just specify the directories the browser should look in.

Because this type of link starts at the root to describe the pathname, it works from any document on the server, regardless of which subdirectory it may be located in. Site root relative links are useful for content that might not always be in the same directory, or for dynamically generated material. They also make it easy to copy and paste links between documents.

On the downside, however, the links won’t work on your local machine, because they will be relative to your hard drive. You’ll have to wait until the site is on the final server to check that links are working.

Writing Pathnames to Images

The src attribute in the img element works the same as the href attribute in anchors. Because you’ll most likely be using images from your own server, the src attributes within your image elements will be set to relative URLs.

Let’s look at a few examples from the Jen’s Kitchen site. First, to add an image to the index.html page, you’d use the following markup:

<img src="images/jenskitchen.gif" alt="">

The URL says, “Look in the current directory (jenskitchen) for the images directory; in there you will find jenskitchen.gif.”

Now for the pièce de résistance. Let’s add an image to the file couscous.html:

<img src="../../images/spoon.gif" alt="">

This is a little more complicated than what we’ve seen so far. This pathname tells the browser to go up two directory levels to the top-level directory and, once there, look in the images directory for an image called spoon.gif. Whew!

Of course, you could simplify that path by going the site root relative route, in which case the pathname to spoon.gif (and any other file in the images directory) could be accessed like this:

<img src="/images/spoon.gif" alt="">

The trade-off is that you won’t see the image in place until the site is uploaded to the server, but it does make maintenance easier once it’s there.

Linking to a Specific Point in a Page

Did you know you can link to a specific point in a web page? This is useful for providing shortcuts to information at the bottom of a long, scrolling page or for getting back to the top of a page with just one click or tap. Linking to a specific point in the page is also known as linking to a document fragment.

Linking to a particular spot within a page is a two-part process. First, identify the destination, and then make a link to it. In the following example, I create an alphabetical index at the top of the page that links down to each alphabetical section of a glossary page (Figure 6-11). When users click the letter H, they’ll jump to the “H” heading lower on the page.

Step 1: Identifying the destination

I like to think of this step as planting a flag in the document so I can get back to it easily. To create a destination, use the id attribute to give the target element in the document a unique name (that’s “unique” as in the name may appear only once in the document, not “unique” as in funky and interesting). In web lingo, this is the fragment identifier.

You may remember the id attribute from Chapter 5, Marking Up Text, where we used it to name generic div and span elements. Here, we’re going to use it to name an element so that it can serve as a fragment identifier—that is, the destination of a link.

Here is a sample of the source for the glossary page. Because I want users to be able to link directly to the “H” heading, I’ll add the id attribute to it and give it the value “startH” (Figure 6-11 1):

<h2 id="startH">H</h2>

Step 2: Linking to the destination

With the identifier in place, now I can make a link to it.

At the top of the page, I’ll create a link down to the “startH” fragment 2. As for any link, I use the a element with the href attribute to provide the location of the link. To indicate that I’m linking to a fragment, I use the octothorpe symbol (#), also called a hash, pound, or number symbol, before the fragment name:

<p>... F | G | <a href="#startH">H</a> | I | J ...</p>

And that’s it. Now when someone clicks the H from the listing at the top of the page, the browser will jump down and display the section starting with the “H” heading 3.

Linking to a Fragment in Another Document

You can link to a fragment in another document by adding the fragment name to the end of the URL (absolute or relative). For example, to make a link to the “H” heading of the glossary page from another document in that directory, the URL would look like this:

<a href="glossary.html#startH">See the Glossary, letter H</a>

You can even link to specific destinations in pages on other sites by putting the fragment identifier at the end of an absolute URL, like so:

<a href="http://www.example.com/glossary.html#startH">See the Glossary, letter H</a>

Of course, you don’t have any control over the named fragments in other people’s web pages. The destination points must be inserted by the author of those documents in order for them to be available to you. The only way to know whether they are there and where they are is to “View Source” for the page and look for them in the markup. If the fragments in external documents move or go away, the page will still load; the browser will just go to the top of the page as it does for regular links.

Exercise 6-8 gives you an opportunity to add links to fragments in the example glossary page.

Targeting a New Browser Window

One problem with putting links on your page is that when people click them, they may never come back to your content. The traditional solution to this dilemma has been to make the linked page open in a new browser window. That way, your visitors can check out the link and still have your content available where they left it.

Be aware that opening new browser windows can cause hiccups in the user experience of your site. Opening new windows is problematic for accessibility, and may be confusing to some users. They might not be able to tell that a new window has opened or they may never find their way back to the original page. At the very least, new windows may be perceived as an annoyance rather than a convenience. So consider carefully whether you need a new window and whether the benefits outweigh the potential drawbacks.

The method you use to open a link in a new browser window depends on whether you want to control its size. If the size of the window doesn’t matter, you can use HTML markup alone. However, if you want to open the new window with particular pixel dimensions, then you need to use JavaScript (see the “Pop-up Windows” sidebar).

To open a new window with markup, use the target attribute in the anchor (a) element to tell the browser the name of the window in which you want the linked document to open. Set the value of target to _blank or to any name of your choosing. Remember that with this method, you have no control over the size of the window, but it will generally open as a new tab or in a new window the same size as the most recently opened window in the user’s browser. The new window may or may not be brought to the front depending on the browser and device used.

Setting target="_blank" always causes the browser to open a fresh window. For example:

<a href="http://www.oreilly.com" target="_blank">O'Reilly</a>

If you include target="_blank" for every link, every link will launch a new window, potentially leaving your user with a mess of open windows. There’s nothing wrong with it, per se, as long as it is not overused.

Another method is to give the target window a specific name, which can then be used by subsequent links. You can give the window any name you like (“new,” “sample,” whatever), as long as it doesn’t start with an underscore. The following link will open a new window called “display”:

<a href="http://www.oreilly.com" target="display">O'Reilly</a>

If you target the “display” window from every link on the page, each linked document will open in the same second window. Unfortunately, if that second window stays hidden behind the user’s current window, it may look as though the link simply didn’t work.

You can decide which method (a new window for every link or reusing named windows) is most appropriate for your content and interface.

Mail Links

Here’s a nifty little linking trick: the mailto link. By using the mailto protocol in a link, you can link to an email address. When the user clicks a mailto link, the browser opens a new mail message preaddressed to that address in a designated mail program (see the “Spam-Bots” sidebar).

A sample mailto link is shown here:

<a href="mailto:alklecker@example.com">Contact Al Klecker</a>

As you can see, it’s a standard anchor element with the href attribute. But the value is set to mailto:name@address.com.

The browser has to be configured to launch a mail program, so the effect won’t work for 100% of your audience. If you use the email address itself as the linked text, nobody will be left out if the mailto function does not work (a nice little example of progressive enhancement).

Telephone Links

Keep in mind that the smartphones people are using to access your site can also be used to make phone calls! Why not save your visitors a step by letting them dial a phone number on your site simply by tapping on it on the page? The syntax uses the tel: protocol and is very simple:

<a href="tel:+01-800-555-1212">Call us free at (800) 555-1212</a>

When mobile users tap the link, what happens depends on the device: Android launches the phone app; BlackBerry and IE11 Mobile initiate the call immediately; and iOS launches a dialog box giving the option to call, message, or add the number to Contacts. Desktop browsers may launch a dialog box to switch apps (for example, to FaceTime on Safari) or they may ignore the link.

If you don’t want any interruption on desktop browsers, you could use a CSS rule that hides the link for non-mobile devices (unfortunately, that is beyond the scope of this discussion).

There are a few best practices for using telephone links:

• It is recommended that you include the full international dialing number, including the country code, for the tel: value because there is no way of knowing where the user will be accessing your site.
• Also include the telephone number in the content of the link so that if the link doesn’t work, the telephone number is still available.
• Android and iPhone have a feature that detects phone numbers and automatically turns them into links. Unfortunately, some 10-digit numbers that are not telephone numbers might get turned into links, too. If your document has strings of numbers that might get confused as phone numbers, you can turn auto-detection off by including the following meta element in the head of your document. This will also prevent them from overriding any styles you’ve applied to telephone links.

  <meta name="format-detection" content="telephone=no">

Test Yourself

The most important lesson in this chapter is how to write URLs for links and images. Here’s another chance to brush up on your pathname skills.

Using the directory hierarchy shown in Figure 6-12, write out the markup for the following links and graphics.

This diagram should provide you with enough information to answer the questions. If you need hands-on work to figure them out, the directory structure is available in the test directory in the materials for this chapter. The documents are just dummy files and contain no content. I filled in the first one for you as an example. The answers are located in Appendix A.

1. In index.html (the site’s home page), write the markup for a link to the tutorial.html page.

   <a href="tutorial.html">...</a>

2. In index.html, write the anchor element for a link to instructions.html.
3. Create a link to family.html from the page tutorial.html.
4. Create a link to boot.html from the family.html page, but this time, start with the root directory.
5. Create a link back to the home page (index.html) from instructions.html.
6. Create a link to the website for this book (learningwebdesign.com) in the file intro.html.
7. Create a link to instructions.html from the page usa.html.
8. Create a link back to the home page (index.html) from acorn.html.

   We haven’t covered the image (img) element in detail yet, but you should be able to fill in the relative URLs after the src attribute to specify the location of the image files for these examples.

9. To place the graphic arrow.gif on the page index.html, use this URL:

   <img src="                            " alt="">

10. To place the graphic arrow.gif on the page intro.html, use this URL:

    <img src="                            " alt="">

11. To place the graphic bullet.gif on the friends.html page, use this URL:

    <img src="                            " alt="">

Element Review: Links

There’s really only one element relevant to creating hypertext links.

a

href="URL"

target="text string"

7. Adding Images

7

Adding Images

The web’s explosion into mass popularity was due in part to the fact that there were images on the page. Before images, the internet was a text-only tundra.

Images appear on web pages in two ways: embedded in the inline content or as background images. If the image is part of the editorial content, such as product shots, gallery images, ads, illustrations, and so on, then it should be placed in the flow of the HTML document. If the image is purely decorative, such as a stunning image in the background of the header or a patterned border around an element, then it should be added through Cascading Style Sheets. Not only does it make sense to put images that affect presentation in a style sheet, but it makes the document cleaner and more accessible and makes the design much easier to update later. I will talk about CSS background images at length in Chapter 13, Colors and Backgrounds.

This chapter focuses on embedding image content into the flow of the document, and it is divided into three parts. First, we’ll look at the tried-and-true img element for adding basic images to a page the way we’ve been doing it since 1992. It has worked just fine for over 25 years, and as a beginner, you’ll find it meets most of your needs as well.

The second part of this chapter introduces some of the methods available for embedding SVG images (Scalable Vector Graphics) in HTML documents. SVGs are a special case and demand special attention.

Finally, we’ll look at the way image markup has had to adapt to the wide variety of mobile devices with an introduction to new responsive image elements (picture and source) and attributes (srcset and sizes). As the number of types of devices used to view the web began to skyrocket, we realized that a single image may not meet the needs of all viewing environments, from palm-sized screens on slow cellular networks to high-density cinema displays. We needed a way to make images “responsive”—that is, to serve images appropriate for their browsing environments. After a few years of back and forth between the W3C and the development community, responsive image features were added to the HTML 5.1 specification and are beginning to see widespread browser support.

I want to point out up front that responsive image markup is not as straightforward as the examples we’ve seen so far in this book. It’s based on more advanced web development concepts, and the syntax may be tricky for someone just getting started writing HTML (heck, it’s a challenge for seasoned professionals!). I’ve included it in this chapter because it is relevant to adding inline images, but frankly, I wouldn’t blame you if you’d like to skip the “Responsive Image Markup” section and come back to it after we’ve done more work with Responsive Web Design and you have more HTML and CSS experience under your belt.

First, a Word on Image Formats

We’ll get to the img element and other markup examples in a moment, but first it’s important to know that you can’t put just any image on a web page; it needs to be in one of the web-supported formats.

In general, images that are made up of a grid of colored pixels (called bitmapped or raster images, as shown in Figure 7-1, top) must be saved in the PNG, JPEG, or GIF file formats in order to be placed inline in the content. Newer, more optimized WebP and JPEG-XR bitmapped image formats are slowly gaining in popularity, particularly now that we have markup to make them available to browsers that support them.

For vector images (Figure 7-1, bottom), such as the kind of icons and illustrations you create with drawing tools such as Adobe Illustrator, we have the SVG format. There is so much to say about SVGs and their features that I’ve given them their own chapter (Chapter 25, SVG), but we’ll look at how to add them to HTML documents later in this chapter.

If you have a source image that is in another popular format, such as TIFF, BMP, or EPS, you’ll need to convert it to a web format before you can add it to the page. If, for some reason, you must keep your graphic file in its original format (for example, a file for a CAD program), you can make it available as an external image by making a link directly to the image file, like this:

<a href="architecture.eps">Get the drawing</a>

You should name your image files with the proper suffixes—.png, .jpg (or .jpeg), .gif, .webp, and .jxr, respectively. In addition, your server must be configured to recognize and serve these various image types properly. All web server software today is configured to handle PNG, JPEG, and GIF out of the box, but if you are using SVG or one of the newer formats, you may need to deliberately add that media type to the server’s official list.

A little background information may be useful here. Image files, and indeed any media files that may reside on a server, have an official media type (also called a MIME type) and suffixes. For example, SVG has the MIME type image/svg+xml and the suffixes .svg and .svgz.

Server packages have different ways of handling MIME information. The popular Apache server software uses a file in the root directory called htaccess that contains a list of all the file types and their acceptable suffixes. Be sure to add (or ask your server administrator to add) the MIME types of new image formats so they may be served correctly. The server looks up the suffix (.webp, for example) of requested files in the list and matches it with the Content-Type (image/webp) that it includes in its HTTP response to the browser. That tells the browser what kind of data is coming and how to parse it.

Browsers use helper applications to display media they can’t handle alone. The browser matches the suffix of the file in the link to the appropriate helper application. The external image may open in a separate application window or within the browser window if the helper application is a browser plug-in. The browser may also ask the user to save the file or open an application manually. It is also possible that it won’t be able to be opened at all.

Without further ado, let’s take a look at the img element and its required and recommended attributes.

The img Element

The img element tells the browser, “Place an image here.” You’ve already gotten a glimpse of it used to place banner graphics in the examples in Chapter 4, Creating a Simple Page. You can also place an image element right in the flow of the text at the point where you want the image to appear, as in the following example. Images stay in the flow of text, aligned with the baseline of the text, and do not cause any line breaks (HTML5 calls this a phrasing element), as shown in Figure 7-2:

<p>This summer, try making pizza <img src="pizza.png" alt=""> on your grill.</p>

When the browser sees the img element, it makes a request to the server and retrieves the image file before displaying it on the page. On a fast network with a fast computer or device, even though a separate request is made for each image file, the page usually appears to arrive instantaneously. On mobile devices with slow network connections, we may be well aware of the wait for images to be fetched one at a time. The same is true for users using dial-up internet connections or other slow networks, like the expensive WiFi at luxury hotels.

The src and alt attributes shown in the sample are required. The src (source) attribute provides the location of the image file (its URL). The alt attribute provides alternative text that displays if the image is not available. We’ll talk about src and alt a little more in upcoming sections.

There are a few other things of note about the img element:

• It is an empty element, which means it doesn’t have any content. You just place it in the flow of text where the image should go.
• It is an inline element, so it behaves like any other inline element in the text flow. Figure 7-3 demonstrates the inline nature of image elements. When the browser window is resized, a line of images reflows to fill the new width.

  

• The img element is what’s known as a replaced element because it is replaced by an external file when the page is displayed. This makes it different from text elements that have their content right there in the source (and thus are non-replaced).
• By default, the bottom edge of an image aligns with the baseline of text, as shown in Figure 7-2. Using CSS, you can float the image to the right or left margin and allow text to flow around it, crop it to a shape, control the space and borders around the image, and change its vertical alignment. We’ll talk about those styles in Part III.

Providing the Location with src

The value of the src attribute is the URL of the image file. In most cases, the images you use on your pages will reside on your own server, so you will use relative URLs to point to them.

If you just read Chapter 6, Adding Links, you should be pretty handy with writing relative URLs. In short, if the image is in the same directory as the HTML document, you can refer to the image by name in the src attribute:

<img src="icon.gif" alt="">

Developers usually organize the images for a site into a directory called images or img (in fact, it helps search engines when you do it that way). There may even be separate image directories for each section of the site. If an image is not in the same directory as the document, you need to provide the pathname to the image file:

<img src="/images/arrow.gif" alt="">

Of course, you could place images from other websites by using a full URL, like this, but it is not recommended (see Warning):

<img src="http://www.example.com/images/smile.gif" alt="">

Providing Alternative Text with alt

alt="text"

Alternative text

Every img element must also contain an alt attribute that provides a text alternative to the image for those who are not able to see it. Alternative text (also called alt text) should serve as a substitute for the image content—conveying the same information and function. Alternative text is used by screen readers, search engines, and graphical browsers when the image doesn’t load (Figure 7-4).

In this example, a PDF icon indicates that the linked text downloads a file in PDF format. In this case, the image is conveying valuable content that would be missing if the image cannot be seen. Providing the alt text “PDF file” replicates the purpose of the image:

<a href="application.pdf">High school application</a> <img src="images/pdflogo.png alt="PDF file">

A screen reader might indicate the image by reading its alt value this way:

“High school application. Image: PDF file”

Sometimes images function as links, in which case providing alternative text is critical because the screen reader needs something to read for the link. In the next example, an image of a book cover is used as a link to the book’s website. Its alt text does not describe the cover itself, but rather performs the same function as the cover image on the page (indicating a link to the site):

<a href="http://learningwebdesign.com"><img src="/images/LWD_cover.png" alt="Learning Web Design site"></a>

If an image does not add anything meaningful to the text content of the page, it is recommended that you leave the value of the alt attribute empty (null). In the following example, a decorative floral accent is not contributing to the content of the page, so its alt value is null. (You may also consider whether it is more appropriately handled as a background image in CSS, but I digress.) Note that there is no character space between the quotation marks:

<img src="/images/floralembellishment.png" alt="">

For each inline image on your page, consider what the alternative text would sound like when read aloud and whether that enhances the experience or might be obtrusive to a user with assistive technology.

Alternative text may benefit users with graphical browsers as well. If the user has opted to turn images off in the browser preferences or if the image simply fails to load, the browser may display the alternative text to give the user an idea of what is missing. The handling of alternative text is inconsistent among modern browsers, however, as shown in Figure 7-4.

Providing the Dimensions with width and height

The width and height attributes indicate the dimensions of the image in number of pixels. Browsers use the specified dimensions to hold the right amount of space in the layout while the images are loading rather than reconstructing the page each time a new image arrives, resulting in faster page display. If only one dimension is set, the image will scale proportionally.

These attributes have become less useful in the age of modern web development. They should never be used to resize an image (use your image-editing program or CSS for that), and they should be omitted entirely when you’re using one of the responsive image techniques introduced later in this chapter. They may be used with images that will appear at the same fixed size across all devices, such as a logo or an icon, to give the browser a layout hint.

Be sure that the pixel dimensions you specify are the actual dimensions of the image. If the pixel values differ from the actual dimensions of your image, the browser resizes the image to match the specified values (Figure 7-5). If you are using width and height attributes and your image looks distorted or even slightly blurry, check to make sure that the values are in sync.

Now that you know the basics of the img element, you should be ready to add a few photos to the Black Goose Bistro Gallery site in Exercise 7-1.

<p><img src="thumbnails/bread-200.jpg" alt="close-up of sliced rustic bread" width="200" height="200"><br>We start our day at the…

That takes care of the basics of adding images to a page. Next we’ll take on adding SVG images, which are a special case, both in terms of the underlying format and the ways they can be added to HTML.

Adding SVG Images

No lesson on adding images to web pages would be complete without an introduction to adding SVGs (Scalable Vector Graphics). After all, the popularity of SVG images has been gaining momentum thanks to nearly ubiquitous browser support and the need for images that can resize without loss of quality. For illustration-style images, they are a responsive dream come true. I’m saving my deep-dive into all things SVG for Chapter 25, but for now I’ll give you a quick peek at what they’re made of so that the embedding markup makes sense.

As I mentioned at the beginning of this chapter, SVGs are an appropriate format for storing vector images (Figure 7-1). Instead of a grid of pixels, vectors are made up of shapes and paths that are defined mathematically. And even more interesting, in SVGs those shapes and paths are specified by instructions written out in a text file. Let that sink in: they are images that are written out in text! All of the shapes and paths as well as their properties are written out in the standardized SVG markup language (see Note). As HTML has elements for paragraphs (p) and tables (table), SVG has elements that define shapes like rectangle (rect), circle (circle), and paths (path).

A simple example will give you the general idea. Here is the SVG code that describes a rectangle (rect) with rounded corners (rx and ry, for x-radius and y-radius) and the word “hello” set as text with attributes for the font and color (Figure 7-7). Browsers that support SVG read the instructions and draw the image exactly as I designed it:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 300 180">  <rect width="300" height="180" fill="purple" rx="20" ry="20"/>  <text x="40" y="114" fill="yellow" font-family="'Verdana-Bold'" font-size="72">    hello!  </text></svg>

SVGs offer some significant advantages over their bitmapped counterparts for certain image types:

• Because they save only instructions for what to draw, they generally require less data than an image saved in a bitmapped format. That means faster downloads and better performance.
• Because they are vectors, they can resize as needed in a responsive layout without loss of quality. An SVG is always nice and crisp. No fuzzy edges.
• Because they are text, they integrate well with HTML/XML and can be compressed with tools like Gzip and Brotli, just like HTML files.
• They can be animated.
• You can change how they look with Cascading Style Sheets.
• You can add interactivity with JavaScript so things happen when users hover their mouse over or click the image.

Again, all of the ins and outs of creating SVGs, as well as their many features, are discussed in detail in Chapter 25. For now, I’d like to focus on the HTML required to place them in the flow of a web page. You have a few options: embedded with the img element, written out in code as an inline svg element, embedded with object, and used as a background image with CSS.

Embedded with the img Element

SVG text files saved with the .svg suffix (sometimes referred to as a standalone SVG) can be treated as any other image, including placing it in the document by using the img element. You’re an expert on the img element by now, so the following example should be clear:

<img src="/images/circle.svg" alt="">

Pros and cons

The advantage to embedding an SVG with img is that it is universally supported in browsers that support SVG.

This approach works fine when you are using a standalone SVG as a simple substitute for a GIF or a PNG, but there are a few disadvantages to embedding SVGs with img:

• You cannot apply styles to the items within the SVG by using an external style sheet, such as a .css file applied to the whole page. The .svg file may include its own internal style sheet using the style element, however, for styling the elements within it. You can also apply styles to the img element itself.
• You cannot manipulate the elements within the SVG with JavaScript, so you lose the option for interactivity. Scripts in your web document can’t see the content of the SVG, and scripts in the SVG file do not run at all. Other interactive effects, like links or :hover styles, are never triggered inside an SVG embedded with img as well.
• You can’t use any external files, such as embedded images or web fonts, within the SVG.

In other words, standalone SVGs behave as though they are in their own little, self-contained bubble. But for static illustrations, that is just fine.

Browser support for SVG with img

The good news is that all modern browsers support SVGs embedded with the img element. The two notable exceptions are Internet Explorer versions 8 and earlier, and the Android browser prior to version 3. As of this writing, users with those browsers may still show up in small but significant numbers in your user logs. If you see a reason for your site to support these older browsers, there are workarounds, which I address briefly in the upcoming “SVG Fallbacks” section.

AddType image/svg+xml .svg

Inline in the HTML Source

Another option for putting an SVG on a web page is to copy the content of the SVG file and paste it directly into the HTML document. This is called using the SVG inline. Here is an example that looks a lot like the inline img example that we saw way back in Figure 7-2, only this time our pizza is a vector image drawn with circles and inserted with the svg element (Figure 7-8). Each circle element has attributes that describe the fill color, the position of its center point (cx and cy), and the length of its radius (r):

<p>This summer, try making pizza  <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 72 72" width="100" height="100">
  <circle fill="#D4AB00" cx="36" cy="36" r="36"/>  <circle opacity=".7" fill="#FFF" stroke="#8A291C" cx="36.1" cy="35.9" r="31.2"/>  <circle fill="#A52C1B" cx="38.8" cy="13.5" r="4.8"/>  <circle fill="#A52C1B" cx="22.4" cy="20.9" r="4.8"/>  <circle fill="#A52C1B" cx="32" cy="37.2" r="4.8"/>  <circle fill="#A52C1B" cx="16.6" cy="39.9" r="4.8"/>  <circle fill="#A52C1B" cx="26.2" cy="53.3" r="4.8"/>  <circle fill="#A52C1B" cx="42.5" cy="27.3" r="4.8"/>  <circle fill="#A52C1B" cx="44.3" cy="55.2" r="4.8"/>  <circle fill="#A52C1B" cx="54.7" cy="42.9" r="4.8"/>  <circle fill="#A52C1B" cx="56" cy="28.3" r="4.8"/></svg>
 on your grill.</p>

This code was generated by Adobe Illustrator, where I created the illustration and saved it in SVG format. I also optimized it to strip out a lot of cruft that Illustrator adds in there. We’ll discuss SVG optimization in Chapter 25.

Pros and cons

Inline SVGs allow developers to take full advantage of SVG features. When the SVG markup is alongside the HTML markup, all of its elements are part of the main DOM tree. That means you can access and manipulate SVG objects with JavaScript, making them respond to user interaction or input. There are similar benefits for style sheets because the elements in the SVG can inherit styles from HTML elements. That makes it easy to apply the same styles to elements on the page and within the SVG graphic.

On the downside, the code for SVG illustrations can get extremely long and unwieldy, resulting in bloated HTML documents that are difficult to read. Even that little pepperoni pizza requires a serious block of code. It also makes the images for a site more difficult to maintain, since they are tucked away in the HTML documents. Another disadvantage is that inline SVGs are not cached by the browser separate from the HTML file, so avoid this method for large images that are reused across many HTML pages.

Browser support

The good news is that all modern browsers support SVG images placed inline with the svg element. The following older browser versions lack support: Internet Explorer versions 8 and earlier, Safari versions 5 and earlier, Android mobile browser prior to version 3, and iOS prior to version 5.

Embedded with the object Element

HTML has an all-purpose media embedding element called object. We’ll talk about it more in Chapter 10, Embedded Media, but for now, know that object is another option for embedding an SVG in a web page. It is a good compromise between img and inline SVG, allowing a fully functional SVG that is still encapsulated in a separate, cacheable file.

The opening object tag specifies the media type (an svg+xml image) and points to the file to be used with the data attribute. The object element comes with its own fallback mechanism—any content within the object gets rendered if the media specified with data can’t be displayed. In this case, a PNG version of the image will be placed with an img if the .svg is not supported or fails to load:

<object type="image/svg+xml" data="pizza.svg">  <img src="pizza.png" alt="pizza"></object>

There is one catch, however. Some browsers download the fallback image even if they support SVG and don’t need it. Useless downloads are not ideal. The workaround is to make the fallback image a CSS background image in an empty div container. Unfortunately, it is not as flexible for scaling and sizing, but it does solve the extra download issue.

<object type="image/svg+xml" data="pizza.svg">  <div style="background-image: url(pizza.png); width 100px; height: 100px;" role="img" aria-label="pizza"></object>

Pros and cons

The main advantage to embedding SVGs with the object element is that they can be scripted and load external files. They can also use scripts to access the parent HTML document (with some security restrictions). However, because they are separate files and not part of the DOM for the page, you can’t use a style sheet in the HTML document to style elements within the SVG. Embedded SVGs may also have some buggy behaviors in browsers, so be sure to test thoroughly.

Used as a Background Image with CSS

I know that this is an HTML chapter, but I’d be remiss if I didn’t at least mention that SVGs can be used as background images with CSS. This style rule example puts a decorative image in the background of a header:

header {  background-image: url(/images/decorative.svg);}

SVG Fallbacks

As mentioned earlier, all modern browsers support SVGs either embedded as an img, embedded as an object, or included inline, which is very good news. However, if your server logs show significant traffic from Internet Explorer 8 and earlier, Android version 3 and earlier, or Safari 5 and earlier, or if your client just requires support for those browsers, you may need to use a fallback technique. One option is to use the object element to embed the SVG on the page and take advantage of its fallback content feature shown earlier.

If you are using SVG as an image with the img element, another option is to use the picture element (it’s discussed as part of the “Responsive Image Markup” section later in this chapter). The picture element can be used to provide several versions of an image in different formats. Each version is suggested with the source element, which in the following example points to the pizza.svg image and defines its media type. The picture element also has a built-in fallback mechanism. If the browser doesn’t support the suggested source files, or if it does not support the picture element, users will see the PNG image provided with the good old img element instead:

<picture>  <source type="image/svg+xml" srcset="pizza.svg">  <img srcset="pizza.png" alt="No SVG support"></picture>

If you Google for “SVG fallbacks,” you’ll likely get quite a few hits, many of which use JavaScript to detect support. For more detailed information on SVG fallbacks, I recommend reading Amelia Bellamy-Royd’s article, “A Complete Guide to SVG Fallbacks” (css-tricks.com/a-complete-guide-to-svg-fallbacks/) or Chris Coyier’s book, Practical SVG (A Book Apart) when you are ready. Ideally, you will be reading this in a world where old Internet Explorer and Android versions are no longer an issue.

Are you ready to give SVGs a spin? Try out some of the embedding techniques we discussed in Exercise 7-2.

Responsive Image Markup

Pretty quickly after smartphones, tablets, “phablets,” and other devices hit the scene, it became clear that large images that look great on a large screen were overkill on smaller screens. All that image data…downloaded and wasted. Forcing huge images onto small devices slows down page display and may cost real money too, depending on the user’s data plan (and your server costs). Conversely, small images that download quickly may be blurry on large, high-resolution screens. Just as we need a way to make whole web pages respond and adapt to various screen sizes, we need a way to make images on those page “responsive” as well. Our trusty img element with its single src attribute just doesn’t cut it in most cases.

It took a couple of years of proposals, experimentation, and discussion between browser makers and the web development community, but we now have a way to suggest alternate images by using HTML markup alone. No complicated JavaScript or server-side hacks. The resulting responsive image features (srcset and sizes attributes as well as the picture element) have been incorporated into the HTML 5.1 specification, and browser support is growing steadily, led by the Chrome browser in September 2014.

Thanks to a foolproof fallback and scripts that add support to older browsers, you can start using these techniques right away. That said, none of this is set in stone. Responsive image solutions are likely to be tweaked and improved, or perhaps one day even made obsolete. If you are going to include them in your sites, a good starting place for getting up-to-speed is the Responsive Images Community Group (responsiveimages.org). RICG is a group of developers who worked together to hammer out the current spec with the browser creators. They are on top of this stuff. You should also look for recent articles and perhaps even crack open the spec.

How It Works

When we say “responsive images,” we are talking about providing images that are tailored to the user’s viewing environment. First and foremost, responsive image techniques prevent browsers on small screens from downloading more image data than they need. They also include a mechanism to give high-resolution displays on fast networks images large enough to look extra-gorgeous. In addition, they provide a way for developers to take advantage of new, more efficient image formats.

In short, responsive images work this way: you provide multiple images, sized or cropped for different screen sizes, and the browser picks the most appropriate one based on what it knows about the current viewing environment. Screen dimensions are one factor, but resolution, network speed, what’s already in its cache, user preferences, and other considerations may also be involved.

The responsive image attributes and elements address the following four basic scenarios:

• Providing extra-large images that look crisp on high-resolution screens
• Providing a set of images of various dimensions for use on different screen sizes
• Providing versions of the image with varying amount of detail based on the device size and orientation (known as the art direction use case)
• Providing alternative image formats that store the same image at much smaller file sizes

Let’s take a look at each of these common use cases.

High-Density Displays (x-descriptor)

Everything that you see on a screen display is made up of little squares of colored light called pixels. We call the pixels that make up the screen itself device pixels (you’ll also sometimes see them referred to as hardware pixels or physical pixels). Until recently, screens commonly fit 72 or 96 device pixels in an inch (now 109 to 160 is the norm). The number of pixels per inch (ppi) is the resolution of the screen.