Show
Chapter 1. Creating Your First PageEvery website is a collection of web pages, so it should come as no surprise that your journey to build a complete site starts here, with the writing of a single web page. Technically, a web page is a special type of document written in a computer language called HTML (that’s short for HyperText Markup Language). Web pages are written for web browsers—programs like Internet Explorer, Google Chrome, and Safari. These browsers have a simple but crucially important job: they read the HTML in a web page document and display the perfectly formatted result for you to read. This chapter will introduce you to HTML. You’ll see how a basic web page works and learn how to create one of your own. For now, you’ll be working with web pages you store on your computer, visible only to you. Later on, in Chapter 9, you’ll learn to put web pages online so anyone with a web connection can see them. HTML: The Language of the WebHTML is the single most important standard in web design—and the only one that’s absolutely required if you plan to create a web page. Every web page is written in HTML. It doesn’t matter whether your page contains a series of blog entries, a dozen pictures of your pet lemur, or a heavily formatted screenplay—odds are that, if you’re looking at it in a browser, it’s an HTML page. HTML plays a key role in web pages: It tells browsers how to display the contents of a page, using special instructions called tags that tell a browser when to start a paragraph, italicize a word, or display a picture. To create your own web pages, you need to learn to use this family of tags. HTML is such an important standard that you’ll spend a good portion of this book digging through its features, frills, and occasional shortcomings. Every web page you build along the way will be a bona fide HTML document. NoteThe HTML standard doesn’t have anything to do with the way a web browser retrieves a page on the Web. That task is left to another standard, called HTTP (HyperText Transport Protocol), which is a communication technology that lets two computers exchange data over the Internet. To use the analogy of a phone conversation, the telephone wires represent HTTP, and the juicy tidbits of gossip you exchange with Aunt Martha are the HTML documents. Cracking Open an HTML FileOn the inside, an HTML page is actually nothing more than a plain-vanilla text file. That means that the raw code behind every web page you create will consist entirely of letters, numbers, and a few special characters (like spaces, punctuation marks, and everything else you can spot on your keyboard). Figure 1-1 dissects an ordinary (and very simple) HTML document. Here’s one of the secrets of web page writing: You don’t need a live website to start creating your own web pages. That’s because you can easily build and test pages using only your own computer. In fact, you don’t even need an Internet connection. The only tools you need are a basic text editor and a standard web browser. Your Text EditorA text editor lets you create or edit an HTML file (in a window like the one you can see in Figure 1-1, bottom). Even many professional web designers stick with simple text-editing tools. There are plenty of fancier editing tools that are designed specifically for editing websites, but you don’t actually need any of them. And if you start using them too soon, you’re likely to end up drowning in a sea of extra frills and features before you really understand how HTML works. Figure 1-1. Every HTML document is actually an ordinary text file. Top: A web browser displays a simple HTML document, showing all its glorious formatting. Bottom: But when you open the same document in a text editor, you see all the text from the original document, along with a few extra pieces of information inside angle brackets The type of text editor you use depends on your computer’s operating system:
Mac fans need to tweak the way TextEdit works because the program has an “HTML view” that hides the tags in an HTML file and shows you the formatted page instead. This behavior is aimed at making life simpler for newbies, but it presents a serious danger for anyone who wants to write a real web page. To avoid confusion and to make sure you write real, raw HTML, you need to turn HTML view off. Here’s how:
Your Web BrowserAs you no doubt know, a web browser is a program that lets you navigate to and display web pages. Without browsers, the Web would still exist, but you wouldn’t be able to look at it. A browser’s job is surprisingly simple—in fact, the bulk of its work consists of two tasks. First, it requests web pages, which happens when you type in a website address (like www.google.com) or click a link in a web page. The browser sends that request to a far-off computer called a web server. A server is typically much more powerful than a home computer because it needs to handle multiple browser requests at once. The server heeds these requests and sends back the content of the desired web pages. When the browser gets that content, it puts its second skill into action and renders, or draws, the web page. Technically, this means the browser converts the plain text it receives from the server into a display document based on formatting instructions embedded in the page. The end result is a graphically rich page with different typefaces, colors, and links. Figure 1-3 illustrates the process. Figure 1-3. A web browser is designed to do two things really well: contact remote computers to ask for web pages, and then display those pages on your computer. Although you usually ask your browser to retrieve pages from the Web, you can also use it to view a web page that’s stored on your computer, which is particularly handy when you’re practicing your HTML skills. In fact, your computer already knows that files that end in .htm or .html have web page content. So if you double-click one of these files, your computer launches your web browser automatically. (You can get the same result by dragging a web page file and dropping it on an already-open browser window.) Although ordinary people need only a single web browser, it’s a good idea for web developers-in-training (like yourself) to become familiar with the most common browsers out there (see Figure 1-4). That’s because, when you design your website, you need to prepare for a wide audience of people with different browsers. To make sure your nifty pages don’t turn funky when other people look at them, you should test your site using a variety of browsers, screen sizes, and operating systems. The following list describes the most popular browsers of today:
Tutorial: Creating an HTML FileNow that you’ve prepped your web kitchen, you’re ready to create your very own web page. In this tutorial, you’ll build the basic page that you saw in Figure 1-1. TipLike all the tutorials in this book, you’ll find the solution for this exercise on the companion site at http://prosetech.com/web. Just look in the folder named Tutorial-1-1 (which stands for “Chapter 1, first tutorial,” if you’re curious). Ready to begin? Here’s what to do:
TipHere’s a trick that can help you open HTML files in a hurry. Find your file, and then right-click it (Control-click on a Mac) and choose “Open with.” This pops open a list of programs you can use to open the file. Click Notepad (or TextEdit) in the list to launch a new text editor window and open your HTML file in one fell swoop. If you leave your web browser window open while you edit your HTML file in a text editor, the browser will hold on to the old version of your file. To see your recent changes, save your text file again (choose File→Save) and then refresh the page in your browser (usually, that’s as easy as right-clicking the page and choosing Refresh or Reload). Seeing the HTML of a Live Web PageMost text editors don’t let you open a web page that’s on the Internet. However, web browsers do give you the chance to sneak a peek at the raw HTML that sits behind any web page. If you’re using Internet Explorer, Chrome, Firefox, or just about any browser other than Safari, you can use a shortcut. Once you navigate to the web page you want to examine, right-click anywhere on the page and choose View Source or View Page Source (the exact wording depends on the browser). A new window appears, showing you the raw HTML that underlies the page. If you’re using Safari on a Mac, you have to jump through an extra hoop to see a web page’s HTML. First, switch on the Develop menu by choosing Safari→Preferences→Advanced and then turning on the “Show Develop menu in menu bar” checkbox. Once you do, visit the page you want to dissect and choose Develop→Show Page Source. TipFirefox has a handy feature that lets you home in on just part of the HTML in a complex web page. Just select the text you’re interested in on the page itself, right-click the text, and then choose View Selection Source. Most web pages are considerably more complex than the popsicles.htm example shown in Figure 1-1, so you need to wade through many more HTML tags when you look at the web page markup. You’re also likely to find a dense thicket of JavaScript code stuffed at the top of the page, stripped of all its spacing and almost impossible to read. But even if the markup looks like gibberish, don’t panic. By the time you finish this book, you’ll be able to scan through a jumble of HTML to find the bits that interest you. In fact, professional web developers often use the View Source technique to check their competitors’ work. Now that you know how to peer into existing HTML files and how to create your own, the next step is to understand what goes inside the average HTML file. It all revolves around a single concept—tags. HTML tags are formatting instructions that tell a browser how to transform ordinary text into something visually appealing. If you were to take all the tags out of an HTML document, the resulting page would consist of nothing more than plain, unformatted text. What’s in a TagYou can recognize a tag by looking for angle brackets, two special characters that look like this: For example, one simple tag is the This text isn't bold. <b>This text is bold. On its own, the You can easily
recognize an end tag. They look the same as start tags, except that they begin with a forward slash. That means they start like this This isn't bold. <b>Pay attention!</b> Now we're back to normal. Which a browser displays as:
This example reflects another important principle of browsers: They always process
tags in the order in which you place them in your HTML. To get the bold formatting in the right place, you need to make sure you position the As you can see, the browser has a fairly simple job. It scans an HTML document, looking for tags and switching on and off various formatting settings. It takes everything else (everything that isn’t a tag) and displays it in the browser window. NoteAdding tags to plain-vanilla text is known as marking up a document, and the tags themselves are known as HTML markup. When you look at raw HTML, you may be interested in looking at the content (the text nestled between the tags) or the markup (the tags themselves). Understanding ElementsMost tags come in pairs. When you use a start tag (like Here’s the basic idea: A pair of tags creates a container (see
Figure 1-7). You place content (like text) inside that container. For example, when you use the Figure 1-7. To get bold text, you need to
start with the correct container. It’s the NoteWhen someone refers to the Of course, life wouldn’t be much fun (and computer books wouldn’t be nearly as thick) without exceptions. When you get right down to it, there are really two types of elements:
In this book, all standalone elements include a slash character before the closing NoteIn the not-so-distant past, web developers were forced to use the empty element syntax—that is, tags that end with a forward slash—because it was an official part of the (now superseded)
XHTML language. Today, the trailing slash is optional, so standalone elements can use the same syntax as start tags (which means you can use either Figure 1-8 puts the two types of elements in perspective. Figure 1-8. Top: This snippet of HTML shows both a container element and a standalone element. Bottom: The browser shows the resulting web page. Nesting ElementsIn the previous example, you applied a simple To see nesting in action, you need
another element to work with. For this example, consider what happens if you want to make a piece of text bold and italicized. HTML doesn’t include a single element for this purpose, so you need to combine the familiar This <b><i>word</i></b> has bold and italic formatting. When a browser chews through this scrap of HTML, it produces text that looks like this:
Incidentally, it doesn’t matter if you reverse the order of the This <i><b>word</b></i> has italic and bold formatting. However, you should always make sure that you close tags in the reverse order from which you opened them. In other words, if you apply italic formatting and then bold formatting, you should switch off bold formatting first, and then italic formatting. Here’s an example that breaks this rule: This <i><b>word</i></b> has italic and bold formatting. Browsers can usually sort this out and make a good guess about what you really want, but it’s a dangerous habit to get into as you write more complex HTML. As you’ll see in later chapters, HTML gives you many more ways to nest elements. For example, you can nest one element inside another, and then nest another element inside that one, and so on, indefinitely. NoteIf you’re a graphic-design type, you’re probably itching to get your hands on more powerful HTML tags to change alignment, spacing, and fonts. Unfortunately, in the web world, you can’t always control everything you want. Chapter 2 has the lowdown, and Chapter 3 introduces the best solution, called style sheets. Understanding HTML DocumentsSo far, you’ve considered snippets of HTML—portions of a complete HTML document. This gave you a taste of how HTML works, but you’ll need to step up your game before you can conquer the Web. In this section, you’ll learn about the structure that makes the difference between a scrap of HTML and an official HTML document. The Document Type DefinitionIn the early days of the Internet, web browsers were riddled with quirks. When people designed web pages, they had to take these quirks into account. For example, browsers might calculate the margins around floating boxes of text in subtly different ways, causing pages to look right in one browser but appear odd in another. Years later, the rules of HTML (and CSS, the style sheet standard you’ll learn about in Chapter 3) were formalized. Using these new rules, every browser could display the same page in exactly the same way. But this change caused a serious headache for longstanding browsers, like Internet Explorer, that had lived through the dark ages of HTML. It had to somehow support the new standards while still being able to properly display existing web pages—including those that relied on old quirks. The web community settled on a simple solution. When designing a new, modern web page, you indicate this fact by adding a code called a document type definition (DTD) or doctype, which goes at the very beginning of your HTML document (Figure 1-9). Figure 1-9. The document type definition (DTD) is the first piece of information in an HTML file. It tells the browser what markup standard you used to write the page. When a browser encounters a doctype, it switches into standards mode and renders the page in the most consistent, standardized way possible. The end result is that the page looks virtually identical in every modern browser. But when a browser encounters an HTML document that doesn’t have a doctype, all bets are off. Internet Explorer, for example, switches into the dreaded quirks mode, where it attempts to behave the same way it did 10 years ago, quirks and all. This ensures that really old web pages retain the look they had when they were first created, even if they rely on ancient browser bugs that have long since been fixed. Unfortunately, different browsers behave differently when you view a page without a doctype. You’re likely to get varying text sizes, inconsistent margins and borders, and improperly positioned content. For that reason, web pages without doctypes are bad news, and you should avoid creating them. In the past, web designers used different doctypes to indicate different versions of HTML markup (for example, XHTML, HTML5, or truly old HTML 4.01). But today, web developers almost always use the simple, universal HTML5 doctype: <!DOCTYPE html> Even though this doctype was formalized as part of HTML5, every browser supports it—even old versions of IE that have never heard of HTML5. That’s because the universal doctype doesn’t indicate anything about the HTML version you prefer. Instead, it just indicates that the language is HTML. This one-line doctype simply reflects the true philosophy of HTML—to support documents old and new. For comparison, here’s the much wordier doctype for XHTML 1.0, which you may still stumble across in older web pages: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> Even seasoned web developers had to copy the XHTML 1.0 doctype from an existing web page to avoid typing it in wrong. In this book, all the examples use the HTML5 doctype not only because it’s the current standard, but because it prepares your pages for the future, too. But just because you use this doctype doesn’t mean you can use all of HTML5’s features. In fact, you should avoid most of them for the time being, unless you’re sure they’re well supported by all the browsers that people use today. NoteIn this book, you’ll use only HTML5 features that work in all of today’s browsers. But if you’re interested in learning about the more experimental parts of the language that still have sketchy browser support, check out HTML5: The Missing Manual (O’Reilly). The Basic SkeletonNow you’re ready to fill in the rest of your web page. To create a true
HTML document, you start with three container elements:
This element wraps everything (other than the doctype) in your web page. <head> This element designates the header portion of your document, which includes some information about your web page. The first detail is the title—open your page in a browser, and this title shows up as the caption on the tab. Optionally, the <head> section can also include links to style sheets (which you’ll learn about in Chapter 3) and JavaScript files (Chapter 14). <body> This element holds the meat of your web page, including the actual content you want displayed to the world. There’s only one right way to use these three elements in a page. Here’s their correct arrangement, with the HTML5 doctype at the beginning of the page: <!DOCTYPE html> <html> <head> ... </head> <body> ... </body> </html> Every web page uses this basic framework. The ellipses (…) show where you insert additional information. The spaces between the lines aren’t required—they’re just there to help you see the element structure more easily. Once you have the HTML skeleton in place, you need to add two more container elements to the mix. Every web page requires a Here’s a closer look at the elements you need to add:
This element sets the title for your web page. The title plays several roles. First, web browsers display it in the browser tab or at the top of the browser window. Second, when a visitor bookmarks your page, the browser uses the title as the bookmark’s label. Third, when your page turns up in a web search, the search engine usually displays this title as the first line in the results, followed by a snippet of content from the page. <p> This indicates a paragraph. Web browsers don’t indent paragraphs, but they do add a little space between consecutive paragraphs to keep them separated. Here’s the web page with these two new ingredients (in bold): <!DOCTYPE html> <html> <head> If you open this document in a web browser, you’ll find that the page is blank, but the title appears (as shown in Figure 1-10). Figure 1-10. When a browser displays a web page, it shows the page’s title on the browser’s tab or at the top of the window. But be warned: the title won’t always fit. As it stands right now, this HTML document is a good template for future pages. The basic structure is in place; you simply need to change the title and add some text. That’s the task you’ll undertake next. Tutorial: Building a Complete HTML DocumentIn this tutorial, you’ll learn to assemble your first genuine web page. You’ll be creating an online resumé (skip ahead to The 10 Most Important Elements (and a Few More) to see the final result), but the details apply to any page you create. TipLike all the tutorials in this book, you can find the solution for this exercise on the companion site at http://prosetech.com/web. Just look in the folder named Tutorial-1-2 (short for “Chapter 1, second tutorial”). As you craft this page, adding a list, picture, and headings, it goes through several iterations. The tutorial files include a separate file for each stage of improvement. Adding Your ContentNo matter what sort of page you want to create, you always start out the same way:
Figure 1-11. Welcome to the Web. This page doesn’t have much in the way of HTML goodies (and it probably won’t get Lee hired), but it does represent one of the simplest possible HTML pages you can create. Using the HTML techniques described in the following sections, you can build on this example and give Lee a better resumé. Each time you make changes to your document in the text editor, refresh the page in your web browser to see if you’re still on track. Structuring Your TextAs you start to create more detailed web pages, you’ll quickly discover that building a page isn’t as straightforward as, say, creating a page in Microsoft Word. For example, you may decide to enhance the resumé page by creating a list of skills. Here’s a reasonable first try: <!DOCTYPE html> <html> <head> <title>Hire Me!</title> </head> <body> <p>I am Lee Park. Hire me for your company, because my work is <b>off the hizzle</b>. The trouble appears when you open this seemingly innocent document in your web browser (Figure 1-12). Figure 1-12. HTML disregards line breaks and consecutive spaces, so what appears as neatly organized text in your HTML file can turn into a jumble of text when you display it in a browser. The problem is that HTML ignores extra white space. That includes tabs, line breaks, and extra spaces (anything more than one consecutive space). The first time this happens, you’ll probably stare at your screen dumbfounded and wonder why web browsers are designed this way. But it actually makes sense when you consider that HTML needs to work as a universal standard. Say you customize your hypothetical web page with the perfect spacing, indenting, and line width for your computer monitor. The hitch is, this page may not look as good on someone else’s monitor. For example, some of the text may scroll off the right side of the page, making it difficult to read. And different monitors are only part of the problem. Today’s web pages need to work on different types of devices. Lee Park’s future boss might view Lee’s resumé on anything from the latest widescreen laptop to a tablet computer or smartphone. To deal with this range of display options, HTML uses elements to define the structure of your document. Instead of telling the browser, “Here’s where you go to the next line and here’s where you add four extra spaces,” HTML tells the browser, “Here are two paragraphs and a bulleted list.” It’s up to the browser to display the page, using the instructions you include in your HTML. To correct the resumé example, you need to use more paragraph elements and two new container elements:
Indicates the start of a bulleted list, called an unordered list in HTML lingo. A list is the perfect way to detail Lee’s skills. <li> Indicates an individual item in a bulleted list. Your browser indents each list item
and, for sentences that go beyond a single line, properly indents subsequent lines so they align under the first one. In addition, it precedes each item with a bullet (•). You can use a list item only inside a list element like Here’s the corrected web page (shown in Figure 1-13), with the structural elements highlighted in bold: <!DOCTYPE html> <html> <head> <title>Hire Me!</title> </head> <body> Figure 1-13. With the right elements (as shown in the code on this page), a browser understands the structure of your HTML document and knows how to display it. You can turn a browser’s habit of ignoring line breaks to your advantage. To help make your HTML documents more readable, add line breaks and spaces wherever you want. Web experts often use indentation to make the structure of nested elements easier to understand. In the resumé example, you can see this style in practice. Notice how the list items (the lines starting with the Figure 1-14 analyzes the HTML document using a tree model. The tree model is a handy way to get familiar with the anatomy of a web page, because it shows the page’s overall structure at a glance. However, as your web pages get more complicated, they’ll probably become too complex for a tree model to be useful. Figure 1-14. Here’s another way to look at the HTML you created. The tree model shows you how you nested HTML elements. By following the arrows, you can see that the top-level If you’re a masochist, you don’t need to use any spaces. The previous example is exactly equivalent to the following much-less-readable HTML document: <!DOCTYPE html><html><head><title>Hire Me!</title></head><body><p>I am Lee Park. Hire me for your company, because my work is <b>off the hizzle </b>.</p><p>My skills include:</p><ul><li>Fast typing (nearly 12 words/minute).</li><li> Extraordinary pencil sharpening.</li><li>Inventive excuse making.</li><li> Negotiating with officers of the peace.</li></ul> </body></html> Of course, it’s nearly impossible for a human to write HTML like this without making a mistake. Where Are All the Pictures?Whether it’s a stock chart, a logo for your underground garage band, or a doctored photo of your favorite celebrity, the Web would be pretty drab without pictures. So far, you’ve seen how to put text into an HTML document, but what happens when you need an image? Although it may seem surprising, you can’t store a picture inside an HTML file. There are plenty of good reasons why you wouldn’t want to anyway—your web page files would become really large, it would be hard to modify your pictures or do other things with them, and you’d have a fiendish time editing your pages in a text editor because the image data would make a mess. The solution is to store your pictures as separate files, and then link your HTML document to them. This way, your browser pulls up the pictures and positions them exactly where you want them on your page. The linking tool that inserts pictures is the Although you’ll learn everything you ever wanted to know about web graphics in Chapter 4, it’s worth considering a simple example now. To try this out, you need a web-ready image handy. (The most commonly supported image file types are JPEG, GIF, and PNG.) If you don’t have an image handy, you can download the sample picture leepark.jpg from the Tutorial-1-2 folder. Here’s an example of an <img src="leepark.jpg" alt="Lee Park Portrait" /> Like the However, there’s an obvious difference between the The The name of the second Once you understand the image element, you’re ready to use it in an HTML document. Just place it wherever it makes sense, inside or after an existing paragraph: <!DOCTYPE html>
<html>
<head>
<title>Hire Me!</title>
</head>
<body>
<p>I am Lee Park. Hire me for your company, because my work is <b>off the
hizzle</b>.
Figure 1-15 shows exactly where the picture ends up. Figure 1-15. Here’s a web page that embeds a picture, thanks to the linking power of the image element. To display this document, a web browser performs a separate request to retrieve the image file. As a result, your browser may display the text of the web page before it downloads the graphic, depending on how long the download takes (typically, that’s a fraction of a second). NoteYou’ll learn many more techniques for web graphics, including how to change their size and wrap text around them, in Chapter 4. The 10 Most Important Elements (and a Few More)You’ve now reached the point where you can create a basic HTML document, and you already have several elements under your belt. You know the fundamentals—all that’s left is to expand your knowledge by learning how to use more elements. HTML has a relatively small set of elements. You’ll most likely use fewer than 25 on a regular basis. This is a key part of HTML’s success, because it makes HTML a simple, shared language that anyone can understand. NoteYou can’t define your own elements and use them in an HTML document, because web browsers won’t know how to interpret them. Some elements, like the <p> element that formats a paragraph, are important for setting out the overall structure of a page. These are called block elements. Block elements get extra space—when you add one to a page, the browser starts a new line (separating this block element from the preceding one). The browser also adds a new line at the end of the block element, separating it from the following element. You can place block elements directly inside the Table 1-1. Basic block elements.
Other elements are designed to deal with smaller structural details—for example, snippets of bold or italicized text, line breaks, links that lead to other web pages, and images. These elements are called inline elements. You can put an inline element in a block element, but you should never put a block element inside an inline element. Table 1-2 lists the most useful inline elements. Table 1-2. Basic inline elements.
To make the sample resumé look more respectable, you can use a few of the ingredients from Table 1-1 and Table 1-2. Figure 1-16 shows a revised version of the web page that throws some new elements into the mix. Figure 1-16. Featuring more headings, lists, and a horizontal line, this HTML document adds a little more style to the resumé. Here’s the pumped-up HTML, with the new headings and the horizontal rule highlighted in bold: <!DOCTYPE html> <html> <head> <title>Hire Me!</title> </head> <body> <h2>Hire Me!</h2> <p>I am Lee Park. Hire me for your company, because my work is <b>off the hizzle</b>. As proof of my staggering computer skills and monumental work ethic, please enjoy this electronic resume.</p> Don’t worry if this example has a bit too much markup for you to digest at once. In the next chapter, you’ll get some more practice turning ordinary text into structured HTML. Checking Your Pages for ErrorsEven a web designer with the best intentions can write bad markup and break the rules of HTML. Although browsers really should catch these mistakes, virtually none of them do. Instead, they do their best to ignore mistakes and display flawed documents. At first glance, this seems like a great design—after all, it smooths over any minor slip-ups you might make. But there’s a dark side to tolerating mistakes. In particular, this behavior makes it all too easy for serious errors to lurk undetected in your web pages. What’s a serious error? A problem that’s harmless when you view the page in your favorite browser but makes an embarrassing appearance when someone views the page in another browser; a mistake that goes undetected until you edit the code, which inadvertently exposes the problem the next time your browser displays the page; or an error that has no effect on page display but prevents an automated tool (like a search engine) from reading the page. Fortunately, there’s a way to catch problems like these. You can use a validation tool that reads through your web page and checks its markup. If you use a professional web design tool like Dreamweaver, you can use its built-in error-checker (Chapter 5 has the details). If you create pages by hand in a text editor, you can use a free online validation tool (see below). Here are some potential problems that a validator can catch:
You can find plenty of validation tools online. The following steps show how to use the popular validator provided by the W3C standards organization (the official owners of the HTML language). Try it out with the resume.htm file you created in the second tutorial
(Tutorial: Building a Complete HTML Document). Or give the validator something to complain about with the popsicles.htm file you created in the first tutorial
(Tutorial: Creating an HTML File). Because it’s an HTML snippet, not a full HTML document, the validator is quick to complain about the missing bits, like the required Once you decide what you want to validate, here’s what to do:
Figure 1-18. In this file, the validator has discovered 10 errors that stem from two mistakes. First, the page is missing the mandatory Which of the following is the first step in adding a Web page to the favorite list?Use the address bar at the top of the window to navigate to the web page you'd like to favorite.. Press Ctrl + D , or click the. icon on the right side of the address bar.. In the menu that appears, name the favorite (A), select the folder you want it saved in (B), and click the Done button (C).. When typing multiple email addresses in the To or Cc text boxes you can separate each address by?You can separate multiple addresses using a comma, space or by pressing the enter key. To send a copy of your mail to secondary recipients, you must add each one as a CC recipient.
What is a standardized procedure used by computers to exchange information?protocol, in computer science, a set of rules or procedures for transmitting data between electronic devices, such as computers.
Which of the following features allows you to quickly minimize all open Windows?You can also use the shortcut key "Windows logo key+m" to minimize all the windows.
|