Demystifying Code

Web pages are built using HTML. This chapter focuses on the latest version, HTML5, finalized in October 2014, and some elements of HTML 4.01. The W3C took eight years to finalize the new standard, and HTML5 is a key element in web development for mobile devices, particularly as it has built-in support for playing media files. HTML5 also frees developers from having to rely so heavily on JavaScript and plug-ins such as Flash. Although web developers are increasingly turning to HTML5, you may still need to work with older sites designed with the older HTML 4.01 standard, so it’s a good idea to understand what’s changed. Happily, HTML5 still supports many HTML 4.01 standards, so updating a site to HTML5 doesn’t have to be overly complicated. Be aware that HTML is an evolving language and that the W3C is already working on HTML 5.1. You can keep tabs on the latest HTML5 decisions on the W3C website (http://www.w3.org); if the information on that site is too technical for you, read the latest tech blogs and other well-updated sites about HTML5.

HTML files are essentially just text files. In Figure 7.1, you can see one of the text files that controls what the browser will display. You can create HTML files using nothing more than a basic text editor such as Notepad in Windows. You can also create HTML by using a wide range of automated and semi-automated tools ranging from standalone web design software, such as Dreamweaver, to online web authoring tools such as WordPress, Blogger, and Wix. All these have a what-yousee-is-what-you-get (WYSIWYG) editing function that allows you to create a web page in much the same way you use a word processor. With many programs able to write HTML for you, more than a few people have asked the question, “Wait, why exactly am I spending all this time learning HTML?” There are a number of good answers to that question.

Figure 7.1 HTML and CSS, the guts behind the page.

First, HTML has limitations, and if you don’t understand the basics of how HTML works, you won’t understand why the WYSIWYG editor won’t always do what you want it to do. Second, the WSIWYG editors don’t always write the best code, nor does the code they write always do exactly what you want it to do. If you don’t understand how HTML works, you can’t sneak in and tweak the code to fix the problems. This issue is particularly important if you want to customize the look of a WordPress or Blogger page beyond the point-and-click options they give you. In short, if you are at all serious about working with the web, you need to understand HTML and Cascading Style Sheets (CSS), which largely control how the page will appear to users. Sometimes CSS code is put in the HTML itself, but often (and usually better), it is put into a separate file.

A good web developer uses HTML to label the pieces of a document according to their functions (navigation, headings, picture captions, paragraphs, list items, etc.) and uses CSS to control how those pieces look and behave (colors, positions on a page, actions like rollover effects, etc.). In other words, the developer uses HTML to mark for meaning and uses structure—semantic markup—to separate function from how elements on a page are presented, an idea explored in more depth in chapter 4 (under “Content and Form”). Among other things, this approach allows developers to change the look of a site across platforms such as phones, tablets, and computers and to apply a redesign with ease.

Figure 7.2 How tagging works.

Rather than being a programming language, HTML lets you put tags (markup) around your text so the browser knows how to display it on the screen, which words or other objects are links, and where to go if you select a link, among other things. The graphics used in a web page are not actually inside the text document, but are referenced in the code and then uploaded along with the HTML file to the server. Formatting the text works much like a word processor, assuming you had to type in the commands to make things bold, italicized, and so on, which once upon a time you actually had to do. Most, but not all, elements have a start tag and an end tag (also called opening and closing tags), which tell the browser to start doing something and to stop doing something. Some resources call the tag an element, but technically an element is everything from the start tag to the end tag and in between. Figure 7.2 shows one way to render text in bold.

In addition to marking up how things look graphically, you can also mark up the text semantically, giving different parts meaning, as in labeling some text as a paragraph (<p></p>). For many items on a page, that labeling creates the type of visual hierarchy discussed in chapter 5, a hierarchy that allows users to make meaning from a page by instantly seeing the relationships between types of content. And a page with headings, subheadings, and paragraphs separated by white space is easier to navigate than a page that is a wall of undifferentiated text. Semantic markup also makes sense for designing a web page for multiple types of devices and users. Instead of marking something as being in bold (<b></b>), you can mark it as being strong (<strong></strong>). The default presentation in a web browser will be bold for each, but the strong tag carries a meaning: this material is important. A user who is blind might set a browser to read a page, and the text-to-speech software would read that material differently. Or a developer might set that material to display in red on mobile devices. The same distinction is true for italicizing. You could mark up the text to be presented in italics (<i></i>), but it’s better to mark it up semantically as emphasized text (<em></em>). If you decide later to make text tagged with <em> bolded rather than italicized, you can do that without changing the HTML tags. Table 7.1 gives you a list of many of the basic HTML elements you will likely use inside the body of your pages.

Good designers try to use semantic—or meaningful—markup rather than markup that controls presentation alone. So they opt for <em> tags rather than tags like <i> and control how the emphasized text looks in a style sheet, usually in a separate file. We’ll get into that more later. For now, picture labeling your text in meaningful ways—with chunks marked up as headings, paragraphs, lists, block quotes, images, links, and emphasized text—and having a separate file control how it all looks. You might have a 500-page site but, at a whim, you could change that one style sheet file and make all the paragraphs display in Arial rather than in Times New Roman without changing anything in those 500 pages. Handy, no? This technique is a much better way to manage a big site. It also lets you include a separate style sheet for mobile devices so users can easily get to your information on their phones and tablets. Also important, it gives visually impaired users who rely on assistive technology (including screen readers that read pages aloud) an idea of what your text means. Instead of marking up a piece of text so it’s presented as Arial 14-point bold, you could mark it up as a heading, and the screen reader would read it aloud as a heading!

The declaration(s) come first, and the head and body are between the HTML tags. Your basic tags for an HTML5 page will look something like Figure 7.3.

Look back at that sample of code in Figure 7.3. Notice how the head and body tags are inside the HTML tags? This is called nesting. Have you ever had a set of nesting dolls, the two-part hollow dolls that stack inside each other? Tags work the same way. You have to make sure the start and end tags in one pair of tags fit completely inside the start and end tags of another pair. Just like it wouldn’t work if you tried to put the head of a small doll on once the bottom is already sealed in a larger doll, as you can see in Figure 7.4, your HTML won’t work if you don’t nest the tags properly. HTML5 lets you leave the end tags off certain elements, but you can also include those end tags. Because older versions of HTML require them for most elements—as do many elements in HTML5—consistently using end tags is a good practice, with exceptions.

Figure 7.3 HTML5 sample.

Figure 7.4 Nesting HTML tags.

Some types of elements often deal with bigger chunks of information than others and usually begin on a new line. These are called block-level elements. Examples include paragraphs, lists, and list items (the separate bulleted or numbered items in a list). In contrast, inline elements such as strong tags often control small chunks of information and are used within a block-level element. In the example shown in Figure 7.4, the paragraph element is block level, and the strong element is inline. You can nest some block-level elements in others, and you can nest inline elements in block-level elements, but you can’t nest block-level elements in inline elements (so you can’t put paragraph tags between bold tags).

Let’s take another look at the parts of an HTML page. While the browser knows it’s looking at HTML, without the doctype declaration, it doesn’t know which type of HTML. The W3C periodically issues new HTML standards, and the browser needs to know which version (doctype) is being used so it can correctly interpret and render the page. If you don’t include a doctype, the browser may not render the page correctly. Once all browsers support (correctly interpret and render) HTML5, you’ll be able to reliably use that simple piece of code: <!DOCTYPE html>. If you are using HTML 4.01, the code is a bit more complicated, and you may want to cut and paste it directly from a reliable source, such as the W3C. Here’s an example of one option for defining an HTML 4.01 document:

Unless you are working with an existing website, however, you should be able to avoid HTML 4.01. HTML5 offers new features, including new block-level elements. As we go through the structure of the HTML document, we will discuss many of the new HTML5 block-level elements, as well as ways to code HTML5 documents to be compatible with older browsers.

Now let’s look at some body tags, which control what the user sees. Although the tags in Figures 7.2 to 7.4 are simple, they get more complex. There can be several parts to a tag, as with the hyperlink in Figure 7.5.

Figure 7.5 Anatomy of a basic tag.

Figure 7.6 Anatomy of a complex tag.

HTML5 streamlines code, making it cleaner (less cluttered and more efficient) than in the past and pushing developers to control presentation in external style sheets. You will find examples of older approaches to coding as you analyze pages to see how other people made cool things work, but you are better off controlling styles externally. In older code, especially, you might see examples of more complex attributes as shown in Figure 7.6. Again, though, you are better off controlling colors and other presentation characteristics from a separate style sheet file rather than within the element.

Browsers also ignore blank lines you put between your words, as shown in Figure 7.7. If the browser doesn’t see a command telling it to put extra space between the words (a nonbreaking space, coded as &nbsp;), it won’t put the space in. HTML is generally not case sensitive; even though the doctype is in uppercase, that’s only by convention. Among the exceptions are special character commands, which have to be lowercase. Using lowercase is the best practice because 1) these exceptions exist, 2) lowercase is easier to read, 3) most developers use lowercase, and 4) the practice of using lowercase will prepare you to branch out into similar coding that is case sensitive.

In addition to formatting and defining elements in a web page, you can, of course, create hyperlinks—this is why we use HTML, right? You can create links to spots within your web page, to other pages in your site, and to web pages on other websites. You do this by using the anchor tag with a hypertext reference attribute (<a href></a>). For example, the code in Figure 7.5 would take you to the Focal Press website when you click on the text “Link to Focal Press.”

Figure 7.7 Blank spaces in HTML.

Tech Talk

Special Characters Special character commands, known as character references, are great. They allow you to use symbols (a.k.a. glyphs) that are not part of the standard HTML character set, such as a copyright symbol © and quotation marks (both straight quotes and smart quotes, which are angled to show opening and closing). Displaying symbols like these requires you to use special characters, &copy; and &quot; in this case. Special characters always begin with an ampersand (&) and end with a semicolon. Over 2,200 special characters have names, and you can use numbers instead of names. Special character commands also can solve problems beyond adding characters that otherwise wouldn’t display on a web page. Earlier, you learned that HTML treats five spaces the same way it does a single space. But what if you want five spaces between the words? The special character command &nbsp; (nonbreaking space) will come to the rescue, as Figure 7.8 shows. Table 7.2 shows you a few other characters you might find useful. Many more special characters are listed in easy-to-find online resources.

Figure 7.8 Special characters in HTML.

Table 7.2 Basic HTML Elements within the Body

Glyph	Name	Number	Description
©	©	©	copyright
®	®	®	registered trademark
™	™	™	trademark
&	&	&	ampersand
"	"	"	straight quote
“	“	“	left (opening) double quotation mark
”	”	”	right (closing) double quotation mark
‘	‘	‘	left (opening) single quotation mark
’	’	’	right (closing) single quotation mark
#	#	#	number sign
	 	 	nonbreaking space
—	—	—	em dash
–	–	–	en dash
§	§	§	section
…	…	…	horizontal ellipsis
{	{	{	left curly bracket
}	}	}	right curly bracket
$	$	$	dollar sign
£	£	£	pound sign
@	@	@	commercial at
÷	÷	÷	division sign
ñ	ñ	ñ	lowercase n with tilde

Browsers

One of the challenges to designing web pages is that what looks good in one browser may not always look good in another—the browsers don’t always interpret HTML and other elements the same way. And there are a number of web brows-ers: Firefox, Chrome, Internet Explorer, and Safari, to name a few. Not only is code sometimes interpreted differently between browsers, but different versions of the same browser may behave differently, and the same version of a browser may interpret code a bit differently when run on different platforms (Windows versus Linux versus Apple’s OS X). Part of the problem is that HTML is an evolving language. The meanings of HTML tags sometimes change, new tags are added, and old tags are deprecated (made obsolete and invalid). Watch out for browsers that don’t follow W3C standards. One of the most notorious is IE 6, which often requires special coding. Although it came out in 2001, there are still a small number of people using it, particularly outside the United States.

One thing most graphical browsers have in common is that they rely on plug-ins to show non-HTML-based material, such as video, Flash, Adobe Acrobat, and Microsoft Word files. Plug-ins are software that run inside your web browser and have become an integral part of the Web. When you are designing a web page, you need to be careful about relying too heavily on content that requires plug-ins. If your end user doesn’t have the plug-in, the page won’t work correctly. Also, consider how many people browse the Web on mobile phones and other devices, such as the Kindle. Many types of devices have browsers that may not support all plug-ins. For instance, Flash isn’t currently supported by Apple on the iPhone or iPad. As we move from HTML 4.01 to HTML5, plug-ins are becoming less necessary. That said, at the time this book was written, none of the major browsers was fully HTML5 compliant.

When you develop a page, you need to make sure that users of graphical browsers will see what you want them to see, that mobile users can easily access materials— and the page isn’t just a hard-to-read mini version of the one you designed for the person using a desktop computer—and that other users can access the materials too. While most of us are familiar with graphical web browsers like the ones listed in this section, some text-based browsers are still in use, including Lynx and Bobcat. And you should also think about how users with assistive technology “see” your page. We’ll talk more about that later.

The Network

The Url: Your Address on the Web

Communicating on the Web is a bit like communicating with postal mail—assuming you had to mail off a request for information every time you wanted something. Clicking on a link is like sending a request to a company for a brochure: you have to have the right address for the company (the web address), and you have to have a return address of sorts (at least a temporary address for the company to mail the brochure to). Focal Press’s web address—http://www.focalpress.com—is an example of a Uniform Resource Locator (URL). The URL includes the protocol, or the set of rules that controls how data are exchanged over a network: in this case Hypertext Transfer Protocol (HTTP). Figure 7.9 breaks down the component parts of the URL. It also includes the domain name of the server, focalpress.com, and the local host name, www (the part that says “look on the server Focal Press has named www”). It could include the name of a specific file as well, set off with a slash (as with http://www.focalpress.com/web.aspx), and even a list of folders the computer has to look in to find that file (the path, between slashes after the domain name—/books/film_and_video/—shows the folder structure). Browsers are not limited to just using HTTP. They can also read HTTPS, which is secure HTTP; FTP (File Transfer Protocol), which is used for uploading and downloading files; RTSP (Real-Time Streaming Protocol), which is used for streaming media; and a variety of other protocols.

The server name can be broken down as well, and we do this by reading the dot-separated domains from right to left. The last section, the .com, is a top-level domain (TLD). In this case, it indicates that the site is a commercial domain. A site ending in .gov would be a government (probably American) site. When this text was written, there were over 800 top-level domains, and the number continues to grow. In addition to indicating what type of site a page is on, a top-level domain can also indicate what country the site is located in, for example, .us (United States), .uk (United Kingdom), and .de (Germany—from Deutschland). The middle section, the .focalpress, is a subdomain, or a second-level domain, and usually refers to the name of the organization to which the site belongs. In some cases, organizations may even use third- and fourth-level domains. The front section, in this case www, is a local host name.

Figure 7.9 Anatomy of a Uniform Resource Locator (URL).

If you want to choose a cool domain name— something meaningful and easy to remember— go to a domain name registry service and search to see if the name you want is available. Once you find an available name, you can pay the fee to have that name licensed to you for the year (or prepay to have it licensed for multiple years). You’ll also need a web hosting service, or space you can rent on a server that’s always on. The web host will let you associate your domain name with their IP (Internet Protocol) address. Some web hosting companies provide both domain name licenses and hosting.

Defining a Site and the “Root Folder”

When you are setting up your site, you’ll need to set up a root folder on your local computer (e.g., mysite). This is the folder in which you will store the files for your website. All the files you are using for the site must be in this folder or in folders inside the root folder. Eventually, you’ll need to find the information for publishing your website to the server. Again, unless you are using an older version of Expression Web (Microsoft’s replacement for FrontPage), you will probably be publishing your files using FTP. You’ll need to know the name of the FTP server too; this is probably, but not always, going to be the name of the web server and your root folder on the server. You’ll also need your username and password. In many cases, your web root folder will be named public_html. This is not, however, always the case. You should always find out which folder your files should be stored in before you begin uploading them. When in doubt, check with your local systems administrator or contact your web hosting company’s technical support service.

Establishing a Hierarchy

Most websites have a hierarchy, often with three main page levels, as shown in Figure 7.10:

• ■ Home (your default page, index.htm or index.html)
• ■ Main pages (linked from a main menu)
• ■ Content pages (linked from secondary navigation and from other content pages)

Figure 7.10 A hierarchical site map.

A first step in site design is deciding how many pages you need to link to in the primary navigation (or global navigation) on your homepage and whether you’ll need secondary navigation (also called a submenu). Your navigation area needs to be big enough to accommodate your major links. As you plan what users will click on to reach their destinations, create a chart to figure out how pages can be reached. Try to plan your site so users can reach any page with three or fewer clicks from the homepage. Main menus usually run along the top of the page or the left-hand side of the page. Users are used to navigation being in these areas. Avoid the right and bottom for primary navigation.

Maintaining Site Uniformity and Consistency

Repeating components, particularly the navigation, should be in the same location on each page. Users get frustrated when components move. Here are two approaches to make sure each page looks about the same:

• ■ Design your basic page as a template, and create other pages in your site only from your template. Some web development software allows you to design one page as a template—a page that controls how all the others look—and to make site-wide changes on that one page, making them ideal for larger sites.
• ■ Design one page as index.html; copy the page, rename and save your copy, and edit it, adding a new title and new content.

Major Sections

In Table 7.1, we covered some of the basic HTML you will use to design a page. HTML5 allows you to go further than labeling content in generic divisions. You can and should label the parts of your page according to their functions, as you see in Table 7.3. As these elements come together, you can imagine boxes around them, as you see in Figure 7.11. They serve as places for specific types of content.

Headings

You will probably use headings throughout your website, much like a textbook uses headings. Headings give users a sense of the structure of a site at first glance, and assistive technology allows users to review the headings on a page without wading through all the content. HTML gives you six options for heading sizes: h1 (the largest because it is the first-level heading) through h6 (the smallest). You can define how these headings look by using a style sheet, but the headings will be easy to read and tell apart even if you don’t use a style sheet. Headings automatically appear with space above and below them.

Figure 7.11 Elements on the page.

Paragraphs and Block Quotes

Much of your remaining text will be paragraphs, and you may also use block quotes for indented text. Browsers will put space above and below text with these tags, too.

Lists

Another useful way to mark text is with list tags. You may choose a bulleted list (an unordered list, or <ul>) for items that don’t have to go in a particular order, or a numbered list (an ordered list, or <ol>) for items that are sequential; each uses list items (<li>). Alternatively, you might use a description list (<dl>), in which each item is broken into two pieces, the description term <dt> and the description <dd>. Figure 7.12 outlines the structure of each type of list.

Figure 7.12 The three types of lists.

Creating and Managing Hyperlinks

Linking within the Website

A link works by using an anchor element (<a></a>) with a hypertext reference attribute (href). An anchor is a piece of code that tells the browser that the element is a link of some sort, and the hypertext reference attribute tells it where to jump to, whether that’s on the same page, another file in the site, or another site altogether. The browser needs to receive instructions to make the jump, and those instructions come when you click on a link. If the instructions are to jump to a specific point on the same page, that point needs to have an element that is labeled with an id attribute (essentially, a label for a unique item on the page): a heading might be labeled <h1 id= “intro”>Introduction</a>, or a piece of text might even use anchor tags without the href attribute, labeled as <a id=“tip”>tip for use</a>. Figure 7.13 shows you how to create a link to content on the same page and to separate pages, both within and outside your site.

Figure 7.13 Linking content on the page and linking files.

Linking to other pages also uses a hypertext reference. The hypertext reference will either be a path through your files to one of your documents (a relative URL) or a URL from someone else’s site (an absolute URL), which includes the protocol (e.g., HTTP).

Use a relative URL to link to files in your website. A relative URL is the name of the file and cues to show where it is in your file structure relative to the current page. With this type of URL, you can post your site in another folder on the server but still have all your internal links work. Also, if you change the folder structure, some web design applications will give you the option to automatically rename your URLs so they continue to work. If you use absolute links by mistake, your links likely won’t work correctly when you upload your files, and you’ll have a maintenance headache.

If you want to link to a file in a different folder, you need to indicate the path, or the steps the browser has to take to find the file. Figure 7.14 illustrates a sample file structure.

Let’s say you have everything in a folder named My Work. When you upload your site, you’ll upload the contents of My Work, but not the folder itself. For now, you’re working on the site offline (not the version on the server). A few files would be in that main folder: your homepage (index.htm) and your main pages (about. htm, portfolio.htm, design.htm, and contact.htm). Notice that the site has only one index.htm file, and it’s in the main folder. That folder contains other folders with simple names to organize deeper site content. If this site had images, it would probably have an images folder. Figure 7.15 shows how to structure links between some of the files shown on the right of Figure 7.14, including navigating up and down the directory structure. These navigation rules apply to your image files as well, not just HTML files.

Figure 7.14 A sample file structure.

Figure 7.15 Navigating directory paths in HTML.

Usually, when you click on a link that pulls up another part of the same website, the new page fills the same window or tab the old page filled. This is one cue you’re still in the same site. This is the default way the browser opens links.

Linking Images and Adding Image Information

The image element (<img>) allows you to tell the browser to insert an image into the web page. It’s important to understand that the image is a separate file from the HTML document. As shown in Figure 7.16, there are four critical attributes that need to accompany an img element:

• ■ src: the source, or the location and name of the image file
• ■ width: the image’s width, measured in pixels
• ■ height: the image’s height, measured in pixels
• ■ alt: an alternative text description of the image

Although most elements have both a start and end tag, the image element is a void element, meaning it doesn’t have an end tag: all its information is within one tag. Linking images is much like linking text. Instead of putting text between the start and end <a> tags, you need to refer to the image file you want to link, as in Figure 7.16.

Figure 7.16 Linking images and using alternative text.

Tech Talk

Creating an Email Link Have you ever clicked on an email address and had your computer pull up the email client (like Outlook or Mac Mail)? It’s easy to set up an email link. Start with the same structure as a text link (<a href=), but change the property: instead of using a URL, use mailto and add the email address:

<a href=“mailto:[email protected]”> Email to order this book.</a>

Consider your audience before you add an email link like this. Many people don’t have their email client set up because they either find it difficult to set up or are working on shared computers, as in a computer lab. Instead, they use web interfaces for email: they might go to yahoo.com and Yahoo’s mail service without ever opening Outlook. For these people, it’s a hassle when Outlook or another email client loads unexpectedly. If you choose to add an email link, use the email address as the linked text so 1) people can copy and paste it and 2) people don’t click on a name expecting to get more information about the person. Be aware that automated software collects email addresses for spam. This software collects links typed into web pages and included in email links. As you become more advanced, look into other options for including email addresses.

Most of your users will be able to see the image just fine. Some, however, won’t. Blind users have screen readers to tell them what’s on the page. When these readers encounter a link like the one in Figure 7.16, they can’t tell the user what the picture represents. This problem is particularly frustrating if the image is a graphic button. Even if you create a site for visual artists and expect only sighted users, some images may not be rendered because of errors. To make sure that content is still usable, add an alt attribute to your img element to describe it.

Creating Tables

Originally, HTML tables were designed to hold tabular data—and that is a great use for them. Some designers, unfortunately, use them to lay out web pages by turning off the borders and using the cells to place images, colors, and text right where they want. Don’t fall into this trap. Tables are not as flexible as divs and elements like <nav>: they make your content harder to scale (harder to magnify and shrink) and your job of preparing the page for a different presentation— such as on a mobile phone—tricky, and they frustrate users who rely on assistive technologies like screen readers. (Among other things, imagine having to hear about the table as you listened to a web page being read: “Table with two columns and four rows. Welcome to …”). Tables are still used to hold tabular data, though, so you might use one to show a menu of upcoming yoga courses and their prices at a gym.

Tables are built row by row. Essentially, you tell the browser you want a table, and within that table you want a row, and inside that row you want a cell, another cell, and yet another cell. Then you add another row and continue. Imagine listening to a screen reader read these cells aloud as they are written in the code. You could create quite a mess for your users. So as you develop a table, make sure you build it correctly and use semantic, or meaningful, markup so assistive technology can help readers make sense of the information. Good tables include a summary attribute in the <table> tag, start with a caption, and are then built by row groups in up to three sections in this order:

• ■ Table caption <caption>: This caption serves as a title for the whole table.
• ■ Table head <thead>: This row group contains labels (table headers) for each column. This row group must come first.
• ■ Table foot <tfoot>: This row group contains a footer. Leave it out if you don’t need it. If you include it, though, place the tags right after the end tag for the head.
• ■ Table body <tbody>: This row group contains the cells in the body of the table, or the table data.

Within row groups, create rows and cells:

• ■ Table rows <tr>: In your table head, your row will contain the next elements, the table headers. In your table foot and table body, your rows will contain table data (normal cells).
• ■ Table headers <th>: You can (and should) add a header to each column to label what comes below.
• ■ Table data <td>: Your cells (other than headers) are in table data elements.

Let’s look at a simple table in Figure 7.17. You’ll notice that the width is set to 400 pixels and the border is set to 1 pixel. You can get rid of the border by setting it to 0.

Figure 7.17 The structure of a table.

Margins

Web page real estate is valuable. Although large margins are good on paper, most designers like to have small margins. When you set top and bottom margins, you are setting the space above and below your text and images. This space is added to the very top and bottom of your page. It is not a buffer of space, so it disappears when you scroll down. Left/right margins work in a similar way.

Define the value of your margins using the number of pixels (px) or one of several other measurement units (for instance, % for percent of the page width or height; pt for points; mm for millimeters; or em for em widths, the width of an m in whatever font size you use or whatever font the user’s browser displays). You can define top and bottom margins, and you can also define left and right margins.

Background and Text Colors

Pay attention to your users’ preferences and whether or not you need to tie in a client’s color scheme. Let common sense and color theory guide your choices. Purchase a color wheel or look one up online (you don’t need a precise example to make basic choices). Colors on opposite sides of the wheel, especially intense colors like bright blue and orange or red and green, will appear to vibrate if they’re next to each other. Inverse text (light on dark) can strain your readers’ eyes. Some combinations cause problems for colorblind users. Choose your color scheme carefully, view it on different monitors to make sure the colors look good, and use a visuals checker, such as Vischeck’s free online checker, to make sure the contrast is adequate.

You can use color names for basic colors like blue and yellow. To achieve subtle variations, use hexadecimal codes for other colors (six-digit color codes, each digit using a number 0–9 or letter A–F, such as #0000FF for a common blue). These codes tell your browser how to combine red, green, and blue, giving you well over 16 million colors to choose from. Select colors from the web-safe colors—your web design application will have a palette that will let you choose from 256 colors—or select colors from the color wheel or spectrum in your design application. Most people now have browsers that do a good job of interpreting colors that are not on the web-safe list. Like other presentation characteristics, colors can be set in CSS.

Font Type and Style

First, keep your lines of text short (about 40 to 60 characters per line), and avoid using all capital letters: they make text hard to read. Refer to chapter 8, “Text,” for more tips on designing type for on-screen display.

You’ve got a lot of content to fit on one page. A small font seems like a good idea, but is it really? Probably not. People generally prefer to see a larger font on screen than on paper. Also, you may have users who are aging or wear glasses. Don’t make your site hard for them to read. Another thing to keep in mind is that font size is relative to the font type you choose. In a word processor, 12-point Times New Roman will have smaller letters than 12-point Arial. The same is true for web pages: some font types are larger than others.

Link Characteristics

How do users know what text on a web page is a link or which links they have already followed? A site is more usable if users can identify links and tell which links they have clicked on. Designers set different characteristics for links to make navigating easier using pseudo-classes, such as a:hover, which changes the properties of a link when the cursor is over the link, or a:visited, which changes the color of links to already visited pages. Although links are often to web pages or other files, you can also use them to take users to a specific part of a web page.

If you don’t want your linked text to be blue and underlined, you can change how it appears, but make sure you give the user good cues that the text is linked. Create your links in a distinct color, and style them so the browser adds underlining when you move the cursor over them (mouse over or hover). You can be creative, but apply color theory (such as by choosing colors for effect and selecting color analogs for your link pseudo-classes), and be consistent with link colors throughout your site.

To control text link appearance and states (how the link appears before, during, and after the user interacts with it), use an external style sheet. In your style sheet, you can control these and other states with pseudo-classes (a selector followed by information about the element’s state):

• ■ Unvisited: This is how your link shows up before you click on it. It should stand out from the page. Use the selector a:link.
• ■ Hover: This is how your link appears when you mouse over, or move the cursor over, the link. Use the selector a:hover.
• ■ Active: This is how your link shows up when you are clicking on the link and haven’t yet released the mouse button. Use the selector a:active.
• ■ Visited: This is how your link shows up after you have visited that page or document. Use the selector a:visited.

Like any text, you can control all sorts of properties of your links: margins, background colors, background images, borders, text decoration (like underlining), and so on, creating text-based buttons styled in CSS. The key is setting properties for separate states. Figure 7.18 shows how you can change link colors and make the underlining appear only when you move the cursor over the links.

Figure 7.18 Controlling link pseudo-classes in CSS.

Interactive and Multimedia Web Content

We’ve just skimmed the surface of HTML5 and CSS. You’ve probably visited sites with numerous visual effects, forms, music, videos, games, and so on. Many of these pages don’t yet use HTML5 to work, but instead use an older version of HTML, often relying on JavaScript or another scripting language—essentially bits of programming code that are inserted into the HTML. If you insert interactive features such as accordions (parts of the content that expand and contract when clicked) using Dreamweaver, the editor creates them using JavaScript. JavaScript is usually used as a client-side script, meaning it runs on the user’s computer. It’s free, simple—at least when you compare it to full programming languages—and well supported. Some features use server-side scripting, such as PHP (Hypertext Preprocessor) or ASP (Active Server Pages). These scripting languages are processed (run) by the server and send data back and forth between the user’s computer and the server. If you think you’ll need a server-side scripting language, learn more about your needs and options, and choose one before you choose a host for your site: you’ll have to select a hosting package that supports that language.

In HTML5, your job as a designer will be easier: some of the work of these scripting languages will be done by HTML elements, although scripting languages will still play a role. Where you once had to use scripts to make a page editable, for instance to let users make a list right on the web page, you’ll be able to use the contenteditable tag (<contenteditable></contenteditable>). Where you once had to use a script to pop up a calendar to let someone choose a date for a form, you’ll be able to use a simple input tag (e.g., <input type=“date”>). In other cases, HTML5 elements will pair with scripting to more easily allow users to interact with the page. The canvas element (<canvas></canvas>) is one such case and will let users draw graphs and other things on the web page. HTML5 will also allow you to more easily create drag-and-drop features. If you want to create a form for users to register with your site, you’ll still need a server-side script because you’ll still need to get that data back to your server; however, many design tasks will be easier to accomplish.

To include media—music and video—designers have had to rely on the embed element (<embed></embed>) with lots of extra information in additional tags and hope the user had the right plug-in. Once HTML5 is standard, you’ll reliably be able to use more specific elements, such as audio and video (<audio src=“mysong.ogg”>my song</audio>, <video src=“myvideo.ogg”>my video</video>), without depending on plug-ins. You’ll have to offer the right type of files, though, and HTML5 compatible browsers are not consistent in which media files they will read. You will be able to control how the video plays, the size of the display, and so forth using attributes in the video tag itself. You can set the music or video to autoplay, but you’re better off letting your users decide whether and when to play media. Overall, multimedia features in HTML5 will let your coding be cleaner, let your media work well with the rest of the page, and give users with disabilities keyboard access to controls.

Accessibility Issues

Accessibility was discussed throughout this chapter and in chapter 6, “User Interface Design.” When you think about your audience, always remember that some of your users may have different needs because of disabilities. The most common issue you’ll hear about is users with vision problems. These problems can range from colorblindness to problems reading small print to users who are completely blind and rely on a text reader to use the Web. Other disabilities you should consider are hearing loss, motor control issues (users who can’t use a mouse, for instance), and cognitive problems, including, among others, problems with attention, memory, and reading. As you build your site, make sure it’s usable for users with disabilities. You should ask a wide variety of questions about accessibility as you design your site. Here’s a small sample of questions: Is the information in logical order? Do my links have meaningful text that could, by itself, help the user (or do they say “More”)? Do I have distracting items, such as flashing images? Do video files have captions and transcripts? Would my menus be easy to use if my hand had a bit of a tremor? For more information, go to WebAIM.org, a leading accessibility site. Also visit Section508.gov.

You can make some accommodations or adjustments for disabled users’ needs with small bits of code. One of the easiest accommodations you can make for users with vision problems is putting in alternative text for images, called alt attributes (commonly, but mistakenly, called alt tags). Most web design applications will give you a spot to put this information when you insert an image in your web page. Without alt attributes, all the text reader will tell the user is that there is an image on the page, not what that image is. Alt attributes are critical when you are using images to create hyperlinks or to replace text. One of the nice things about using alternative text is that it will also make life easier for users on slower connections who might have turned images off in their web browser or people who are using a mobile device. Users with motor skill problems may have to navigate using the tab key—an issue you can address by setting the “tab order” on a page.

Use tools to help you fix accessibility problems, but don’t rely on tools alone. Some web design applications prompt you to add alt attributes as you use the WYSIWYG tools, and some have built-in accessibility checkers. Online tools often help you check your pages in more detail. The W3C validator will give you a line-by-line breakdown of coding problems, including accessibility issues such as the possible misuse of H1, and WAVE (http://wave.webaim.org) will give you a visual of your page and flag the problems it detects with red and yellow icons. AChecker will create an accessibility-specific report. Other checkers will allow you to identify problems for colorblind users and even emulate the type of information someone would get if using a screen reader.

Making your page accessible for any of these users will frequently increase the overall usability of the site on both computers and mobile devices. And as you learned in chapter 6, “User Interface Design,” you may have a legal obligation to make your site accessible, too.