Teach Yourself Web Publishing with HTML 3.2 in 14 Days
All About Links
- Creating Links
- Linking Local Pages Using Relative and Absolute Pathnames
- Links to Other Documents on the Web
- Linking to Specific Places Within Documents
- Anatomy of a URL
- Kinds of URLs
After finishing the last chapter, you have a couple pages that
have some headings, text and lists in them. This is all well and
good, but rather boring. The real fun starts when you learn how
to do hypertext links and link up all your pages to the Web, and
in this chapter, you'll learn just that. Specifically, you'll
- All about the HTML link tag (<A>) and its various parts
- How to link to other pages on your local disk using relative and absolute pathnames
- How to link to other pages on the Web using URLs
- Using links and anchors to link to specific places inside pages
- All about URLs: the various parts of the URL and the kinds of URLs you can use
To create a link in HTML, you need two things:
- The name of the file (or the URL of the file) you want to link to
- The text that will serve as the "hot spot"-that is, the text that will be highlighted in the browser, which your readers can then select to follow the link
Only the second part is actually visible on your page. When your reader selects the text that points to a link, the browser uses the first part as the place to "jump" to.
To create a link in an HTML page, you use the HTML link tag <A>...</A>.
The <A> tag is often
called an anchor tag, as it can also be used to create anchors
for links. (You'll learn more about creating anchors later in
this chapter.) The most common use of the link tag, however, is
to create links to other pages.
Unlike the simple tags you learned about in the previous chapter, the <A> tag has some extra features: the opening tag, <A>, includes both the name of the tag ("A") and extra information about the link itself. The extra features are called attributes of the tag. So instead of the opening <A> tag having just a name inside brackets, it looks something like this:
<A NAME="Up" HREF="../menu.html" TITLE="Ostrich Care">
Attributes are extra parts of HTML tags that contain options or other information about the tag itself.
The extra attributes (in this example, NAME, HREF, and TITLE) describe the link itself. The attribute you'll probably use most often is the HREF attribute, short for "Hypertext REFerence." The HREF attribute is used to specify the name or URL of the file where this link points.
Like most HTML tags, the link tag also has a closing tag, </A>. All the text between the opening and closing tags will become the actual link on the screen and be highlighted, underlined, or colored blue or red when the Web page is displayed. That's the text you or your reader will click on (or select, in browsers that don't use mice) to jump to the place specified by the HREF attribute.
Figure 4.1 shows the parts of a typical link using the <A> tag, including the HREF, the text of the link, and the closing tag:
The following two examples show a simple link and what it looks like in Netscape (Figure 4.2) and Lynx (Figure 4.3).
Go back to <A HREF="../menu.html">Main Menu</A>
Exercise 4.1: Link two pages.
Let's try a really simple example, with two HTML pages on your local disk. You'll need your text editor and your Web browser for this, but since both the pages you'll be fooling with are on your local disk, you won't need to be connected to the network. (Be patient; you'll get to do network stuff in the next section of this chapter.)
First, create two HTML pages, and save them in separate files. Here's the code for the two HTML files I created for this section, which I called menu.html and feeding.html. It really doesn't matter what your two pages look like or what they're called, but make sure you put in your own filenames if you're following along with this example.
Don't want to type in these examples? They're contained on the accompanying CD.
The first file is called menu.html file, and it looks like this:
<TITLE>How To Care For Your Ostrich</TITLE>
<H1>Caring for Your New Ostrich</H1>
<P>Your new ostrich is a delicate and sensitive creature. This document
describes how to care for your ostrich so that he can be a happy and healthy ostrich and give you hours of fun and friendship.</P>
<LI>Feeding Your Ostrich
<LI>Grooming Your Ostrich
<LI>Cleaning Up After Your Ostrich
<LI>Taunting Your Ostrich
The list of menu items ("Feeding Your Ostrich," "Grooming Your Ostrich," and so on) will be links to other pages. For now, just type them as regular text; you'll turn them into links later.
The second file, feeding.html, looks like this:
<TITLE>How To Care For Your Ostrich: Feeding Your Ostrich</TITLE>
<H1>Feeding Your Ostrich</H1>
<P>This section describes what, how often, and how to feed your ostrich
<H2>What to Feed Your Ostrich</H2>
Ostriches benefit best from a balanced diet such as that provided by United
Bird Food's Ostrich Kibble 102. We recommend feeding your ostrich a cup of
kibbles once a day, with ample water.
<H2>How to Feed Your Ostrich</H2>
<P>To feed your ostrich, leave the ostrich kibbles in a container by the
edge of the ostrich's pen.</P>
<P>NOTE: Ostriches do not like being watched while eating, and may attack
you if you stand too close. We recommend leaving your ostrich to eat in peace.
<P>Go back to Main Menu</P>
Make sure both your files are in the same directory or folder, and if you haven't called them menu.html and feeding.html, make sure that you take note of the names because you'll need them later.
First, let's create a link from the menu file to the feeding file. Edit the menu.html file, and put the cursor at the line that says <LI>Feeding Your Ostrich.
Link tags do not define the format of the text itself, so leave in the list item tags and just add the link inside the item. First, put in the link tags themselves (the <A> and </A> tags) around the text that you want to use as the link:
<LI><A>Feeding Your Ostrich</A>
Now add the name of the file you want to link to as the HREF part of the opening link tag. Enclose the name of the file in quotes (straight quotes ("), not curly or typesetter's quotes (")), with an equals sign between HREF and the name. Note that uppercase and lowercase are different, so make sure you type the filename exactly as you saved it (Feeding.html is not the same file as feeding.html; it has to be exactly the same case). Here I've used feeding.html; if you used different files, use those different filenames.
<LI><A HREF="feeding.html">Feeding Your Ostrich</A>
Now, start up your browser, select Open File (or its equivalent in your browser), and open the menu.html file. The paragraph that you used as your link should now show up as a link that is in a different color, underlined, or otherwise highlighted. Figure 4.4 shows how it looked when I opened it in the Macintosh version of Netscape:
And now, when you click on the link, your browser should load in and display the feeding.html page, as shown in Figure 4.5.
If your browser can't find the file when you choose the link, make sure that the name of the file in the HREF part of the link tag is the same as the name of the file on the disk, that uppercase and lowercase match, and that both of the files are in the same directory. Remember to close your link, using the </A> tag, at the end of the text that serves as the link. Also, make sure that you have quotes at the end of the filename (sometimes it's easy to forget), and that both quotes are ordinary straight quotes. All of these things can confuse the browser and make it not find the file or display the link properly.
Now, let's create a link from the feeding page back to the menu page. There is a paragraph at the end of the feeding.html page intended for just this purpose:
<P>Go back to Main Menu</P>
Add the link tag with the appropriate HREF to that line, like this, where menu.html is the original menu file:
<P><A HREF="menu.html">Go back to Main Menu</A></P>
When you include tags inside other tags, make sure that the closing tag closes the tag that you most recently opened. That is, do this:
Now when you reload the "feeding" file, the link will be active, and you can jump between the menu and the feeding file by selecting those links.
The example in the previous section shows how to link together pages that are contained in the same folder or directory on your local disk (local pages). This section continues that thread, linking pages that are still on the local disk but may be contained in different directories or folders on that disk.
Folders and directories are the same thing, but they're called different things depending on whether you're on Mac, Windows, DOS, or UNIX. I'll call them simply directories from now on to make things easier.
When you specify just the pathname of a linked file within quotes, as you did earlier, the browser looks for that file in the same directory as the current file. This is true even if both the current file and the file being linked to are on a server somewhere else on the Net; both files are contained in the same directory on that server. This is the simplest form of a relative pathname.
Relative pathnames can also include directory names, or they can point to the path you would take to navigate to that file if you started at the current directory or folder. A pathname might include directions, for example, to go up two directory levels, and then go down two other directories to get to the file.
Relative pathnames point to files based on their locations relative to the current file.
To specify relative pathnames in links, use UNIX-style pathnames regardless of the system you actually have. This means that directory or folder names are separated by forward slashes (/), and you use two dots to refer generically to the directory above the current one (..).
Table 4.1 shows some examples of relative pathnames and what they
|HREF="file.html"||file.html is located in the current directory.|
|HREF="files/file.html"||file.html is located in the directory (or folder) called files (and the files directory is located in the current directory).|
|HREF="files/morefiles/file.html"||file.html is located in the morefiles directory, which is located in the files directory, which is located in the current directory.|
|HREF="../file.html"||file.html is located in the directory one level up from the current directory (the "parent" directory.|
|HREF="../../files/file.html"||file.html is located two directory levels up, in the directory files.|
If you're linking files on a personal computer (Mac or pc) and you want to link to a file on a different disk, use the name or letter of the disk as just another directory name in the relative path.
On the Macintosh, the name of the disk is used just as it appears on the disk itself. Assume you have a disk called Hard Disk 2, and your HTML files are contained in a folder called HTML Files. If you wanted to link to a file called jane.html in a folder called Public on a shared disk called Jane's Mac, you could use the following relative pathname:
On DOS systems, the disks are referred to by letter, just as you would expect them to be, but instead of being c:, d:, and so on, substitute a vertical bar (|) for the colon (the colon has a special meaning in link pathnames), and don't forget to use forward slashes like on UNIX. So, if the current file is located in C:\FILES\HTML\, and you want to link to D:\FILES.NEW\HTML\MORE\INDEX.htm, the relative pathname to that file would be:
In most instances you'll never use the name of a disk in relative pathnames, but I've included it here for completeness. Most of the time you'll be linking between files that are reasonably close (only one directory or folder away) in the same presentation.
You can also specify the link to another page on your local system using an absolute pathname. Relative pathnames point to the page you want to link by describing its location relative to the current page. Absolute pathnames, on the other hand, point to the page by starting at the top level of your directory hierarchy and working downward through all the intervening directories to reach the file.
Absolute pathnames point to files based on their absolute location on the file system.
Absolute pathnames always begin with a slash, which is the way they are differentiated from relative pathnames. Following the slash are all directories in the path from the top level to the file you are linking.
"Top" has different meanings depending on how you're publishing your HTML files. If you're just linking to files on your local disk, the top is the top of your file system (/ on UNIX, or the disk name on a Mac or pc). When you're publishing files using a Web server, the top may or may not be the top of your file system (and generally isn't). You'll learn more about absolute pathnames and Web servers on Day 8, "Going Live on the Web."
Table 4.2 shows some examples of absolute pathnames and what they
|HREF="/u1/lemay/file.html"||file.html is located in the directory /u1/lemay (typically UNIX).|
|HREF="/d|/files/html/file.htm"||file.htm is located on the D: disk in the directories files/html (DOS systems).|
|HREF="/Hard Disk 1/HTML Files/file.html"||file.html is located on the disk Hard Disk 1, in the folder HTML Files (typically a Macintosh).|
To link between your own pages, most of the time you should use relative pathnames instead of the absolute pathnames. Using absolute pathnames may seem easier for complicated links between lots of pages, but absolute pathnames are not portable. If you specify your links as absolute pathnames and you move your files elsewhere on the disk, or rename a directory or a disk listed in that absolute path, then all your links will break and you'll have to laboriously edit all your HTML files and fix them all. Using absolute pathnames also makes it very difficult to move your files to a Web server when you decide to actually make them available on the Web.
Specifying relative pathnames enables you to move your pages around on your own system and to move them to other systems with little or no file modifications to fix the links. It's much easier to maintain HTML pages with relative pathnames, so the extra work of setting them up initially is often well worth the effort.
So now you have a whole set of pages on your local disk, all linked to each other. In some places in your pages, however, you would like to refer to a page somewhere else on the Net; for example, to the Palo Alto Zoo home page for more information on the socialization of ostriches. You can also use the link tag to link those other pages on the Net, which I'll call remote pages.
Remote pages are pages contained somewhere on the Web other than the system you're currently working on.
The HTML code you use to link pages on the Web looks exactly the same as the code you used for links between local pages. You still use the <A> tag with an HREF attribute, and include some text to serve as the link on your Web page. But instead of a filename or a path in the HREF, use the URL of that page on the Web, as Figure 4.6 shows.
Exercise 4.2: Linking your ostrich pages to the Web.
Let's go back to those two pages you linked together earlier in this chapter, the ones about ostriches. The menu.html file contained several links to other local pages that described how to take care of your ostrich.
Now say you want to add a link to the bottom of the menu file to point to the ostrich archives at the Palo Alto Zoo (the world's leading authority on the care of ostriches), whose URL is http://www.zoo.palo-alto.ca.us/ostriches/home.html.
I'm making most of this up as I go along. Although the city of Palo Alto, California, has a Web page (URL http://www.city.palo-alto.ca.us/home.html), Palo Alto doesn't have a zoo with ostriches (they do have a small petting zoo, however). For the purposes of this example, just pretend that there's a Web page for the Palo Alto Zoo.
First, add the appropriate text for the link to your menu page:
<P>The Palo Alto Zoo has more information on ostriches</P>
What if you don't know the URL of the home page for the Palo Alto Zoo (or the page you want to link to), but you do know how to get to it by following several links on several different people's home pages? Not a problem. Use your browser to find the home page for the page you want to link to. Figure 4.7 shows what the home page for the Palo Alto Zoo might look like, if it existed.
If you set up your system (for the previous chapter) so that it would not connect to the network, you might want to put it back now to follow along with this example.
Most browsers display the URL of the file they're currently looking at in a box somewhere near the top of the page (in Netscape, this box may be hidden; choose Show Location from the Options menu to see it). This makes it particularly easy for you to link to other pages; all you have to do is go to the page you want to link to with your browser, copy the URL from the window, and paste it into the HTML page you're working on. No typing!
Once you have the URL of the zoo, you can construct a link tag in your menu file and paste the appropriate URL into the link:
<P>The <A HREF="http://www.zoo.palo-alto.ca.us/ostriches/home.html">Palo Alto Zoo<A>
has more information on ostriches</P>
Of course, if you already know the URL of the page you want to link to, you can just type it into the HREF part of the link. Keep in mind, however, that if you make a mistake, your browser won't be able to find the file on the other end. Most URLs are a little too complex for normal humans to be able to remember them; I prefer to copy and paste whenever I can to cut down on the chances of typing them incorrectly.
Figure 4.8 shows how the menu.html file, with the new link in it, looks when it is displayed by Netscape.
Exercise 4.3: Creating a link menu.
Now that you've learned how to do links in this chapter and lists in the last chapter, you can create what is called a link menu. Link menus are links on your Web page that are arranged in list form or in some other short, easy-to-read, and easy-to-understand format. Link menus are terrific for pages that are organized in a hierarchy, for tables of contents, or for navigation among several pages. Web pages that consist of nothing but links often organize those links in menu form.
Link menus are short lists of links on Web pages that give your readers a quick, easy-to-scan overview of the choices they have to jump to from the current page.
The idea of a link menu is that you use short, descriptive terms as the links, with either no text following the link or with further description following the link itself. Link menus look best in a bulleted or unordered list format, but you can also use glossary lists or just plain paragraphs. Link menus let your reader scan the list of links quickly and easily, something that may be difficult to do if you bury your links in body text.
In this exercise, you'll create a Web page for a set of restaurant reviews. This page will serve as the index to the reviews, so the link menu you'll create is essentially a menu of restaurant names.
Start with a simple page framework: a first-level head and some basic explanatory text:
<TITLE>Laura's Restaurant Guide</TITLE>
<H1>Laura's Restaurant Reviews</H1>
<P>I spend a lot of time in restaurants in the area, having lunches or dinners
with friends or meeting with potential clients. I've written up several reviews
of many of the restaurants I frequent (and a few I'd rather not go back to).
Here are reviews for the following restaurants:</P>
Now add the list that will become the links, without the link tags themselves. It's always easier to start with link text and then attach actual links afterwards. For this list, we'll use a tag to create a bulleted list of individual restaurants. You could use a <MENU> tag here just as easily, but the <OL> tag wouldn't be appropriate, because the numbers would imply that you were ranking the restaurants in some way. Here's the HTML list of restaurants; Figure 4.9 shows the page in Netscape as it currently looks with the introduction and the list.
<LI>The Summit Inn
Now, modify each of the list items so that they include link tags. You'll need to keep the <LI> tag in there because it indicates where the list items begin. Just add the <A> tags around the text itself. Here we'll link to filenames on the local disk in the same directory as this file, with each individual file containing the review for the particular restaurant:
<LI><A HREF="schezuan.html">Szechuan Supreme</A>
<LI><A HREF="mels.html">Mel's Pizza</A>
<LI><A HREF="summitinn.html">The Summit Inn</A>
<LI><A HREF="millieu.html">Cafe Milieu</A>
The menu of restaurants looks fine, although it's a little sparse. Your reader doesn't know what kinds of food each restaurant serves (although some of the restaurant names indicate the kind of food they serve), or if the review is good or bad. An improvement would be to add some short explanatory text after the links to provide a hint of what is on the other side of the link:
<LI><A HREF="schezuan.html">Szechuan Supreme</A>. Chinese food. Prices are
excellent, but service is slow
<LI><A HREF="mels.html">Mel's Pizza</A>. Thin-crust New York style pizza.
Awesome, but loud.
<LI><A HREF="tomi.html">Tomi</A>. Sushi. So-so selection, friendly chefs.
<LI><A HREF="summitinn.html">The Summit Inn</A>. California food. Creative
chefs, but you pay extra for originality and appearance.
<LI><A HREF="millieu.html">Cafe Milieu</A>. Lots of atmosphere, sullen
postmodern waitrons, but an excellent double espresso none the less.
The final list then looks like Figure 4.10.
We'll use link menus similar to this one throughout this book.
The links you've created so far in this chapter have been from one point in a page to another page. But what if, instead of linking to that second page in general, you wanted to link to a specific place within that page; for example, to the fourth major section down?
You can do this in HTML by creating an anchor within the second page. The anchor creates a special thing inside the page which you can link to. The link you create in the first page will contain both the name of the file you're linking to and the name of that anchor. Then, when you follow the link with your browser, the browser will load the second page and then scroll down to the location of the anchor (Figure 4.11 shows an example).
Anchors are special places inside documents that can be linked to. Links can then jump to those special places inside the page as opposed to jumping just to the top of the page.
You can also use links and anchors within the same page so that if you select one of those links, you jump to different places within that same page.
You create an anchor in nearly the same way that you create a link, using the <A> tag. If you had wondered why the link tag uses an <A> instead of an <L>, now you know: A actually stands for Anchor.
When you specified links using <A>, there were two parts of the link: the HREF attribute in the opening <A> tag, and the text between the opening and closing tags that served as a hot spot for the link.
Anchors are created in much the same way, but instead of using the HREF attribute in the <A> tag, you use the NAME attribute. The NAME attribute takes a keyword (or words) that will be used to name that anchor. Figure 4.12 shows the parts of the <A> tag when used to indicate an anchor.
Anchors also require some amount of text between the opening and closing <A> tags, even though they usually point to a single-character location. The text between the <A> tags is used by the browser when a link that is attached to this anchor is selected. The browser scrolls the page to the text within the anchor so that it is at the top of the screen. Some browsers may also highlight the text inside the <A> tags.
So, for example, to create an anchor at the section of a page labeled Part 4, you might add an anchor called Part4 to the heading, like this:
<H1><A NAME="Part4">Part Four: Grapefruit from Heaven</A></H1>
Unlike links, anchors do not show up in the final displayed page. Anchors are invisible until you follow a link that points to them.
To point to an anchor in a link, you use the same form of link that you would when linking to the whole page, with the filename or URL of the page in the HREF attribute. After the name of the page, however, include a hash sign (#) and the name of the anchor exactly as it appears in the NAME attribute of that anchor (including the same uppercase and lowercase characters!), like this:
<A HREF="mybigdoc.html#Part4">Go to Part 4</A>
This link tells the browser to load the page mybigdoc.html and then to scroll down to the anchor name Part4. The text inside the anchor definition will appear at the top of the screen.
Exercise 4.4: Link sections between two pages.
Let's do an example with two pages. These two pages are part of an online reference to classical music, where each Web page contains all the references for a particular letter of the alphabet (A.html, B.html, and so on). The reference could have been organized such that each section was its own page. Organizing it that way, however, would have involved an awful lot of pages to manage, as well as an awful lot of pages the reader would have to load if they were exploring the reference. It's more efficient in this case to bunch the related sections together under lettered groupings. (Chapter 11, "Writing and Designing Web Pages: Dos and Don'ts," goes into more detail about the trade-offs between short and long pages.)
The first page we'll look at is the one for "M," the first section of which looks like this in HTML (Figure 4.13 shows how it looks when it's displayed):
<TITLE>Classical Music: M</TITLE>
<LI>William Byrd, <EM>This Sweet and Merry Month of May</EM>
<LI>William Byrd, <EM>Though Amaryllis Dance</EM>
<LI>Orlando Gibbons, <EM>The Silver Swan</EM>
<LI>Roland de Lassus, <EM>Mon Coeur se Recommande à vous</EM>
<LI>Claudio Monteverdi, <EM>Lamento d'Arianna</EM>
<LI>Thomas Morley, <EM>My Bonny Lass She Smileth</EM>
<LI>Thomas Weelkes, <EM>Thule, the Period of Cosmography</EM>
<LI>John Wilbye, <EM>Sweet Honey-Sucking Bees</EM>
<P>Secular vocal music in four, five and six parts, usually a capella.
Byrd, Gibbons, Lassus, Monteverdi, Morley, Weelkes, Wilbye</P>
In that last line (the See Also), it would be useful to link those composer names to their respective sections elsewhere in the reference. If you used the procedure you learned previously in this chapter, you'd create a link here around the word Byrd to the page B.html. When your readers selected the link to B.html, the browser would drop them at the top of the Bs. Those hapless readers would then have to scroll down through all the composers that start with B (and there are lots of them: Bach, Beethoven, Brahms, Bruckner) to get to Byrd; a lot of work for a system that claims to link information so you can find what you want quickly and easily.
What you want is to be able to link the word Byrd in M.html directly to the section for Byrd in B.html. Here's the relevant part of B.html you want to link (I've deleted all the Bs before Byrd to make this file shorter for this example. Pretend they're still there).
<TITLE>Classical Music: B</TITLE>
<!-- I've deleted all the Bs before Byrd to make things shorter -->
<H2>Byrd, William, 1543-1623</H2>
<LI><EM>This Sweet and Merry Month of May</EM>
<LI><EM>Though Amaryllis Dance</EM>
<LI><EM>Lullabye, My Sweet Little Baby</EM>
<LI><EM>Mass for Five Voices</EM>
<LI><EM>Mass for Four Voices</EM>
<LI><EM>Mass for Three Voices</EM>
<LI><EM>Ave verum corpus a 4</EM>
Madrigals, Masses, Motets</P>
What you'll need to do here is to create an anchor at the section heading for Byrd. You can then link to that anchor from the See Alsos in the file for M.
As I described in the previous section, you need two things for each anchor: an anchor name and the text inside the link to hold that anchor (which may be highlighted in some browsers). The latter is easy; the section heading itself works well, as that's the thing you're actually linking to.
For the anchor name, you can choose any name you want, but each anchor in the page must be unique. (If you had two or more anchors with the name fred in the same page, how would the browser know which one to choose when a link to that anchor is selected?) A good unique anchor name for this example would be simply Byrd because there's only one place Byrd could appear in the file, and this is it.
With the two parts decided on, you can create the anchor itself in your HTML file. Add the <A> tag to the William Byrd section heading, but be careful here. If this was normal text within a paragraph, you'd just surround the whole line with <A>. But when you're adding an anchor to a big section of text that is also contained within an element-such as a heading or paragraph-always put the anchor inside the element. In other words, do this:
<H2><A NAME="Byrd">Byrd, William, 1543-1623</A></H2>
But not this:
<A NAME="Byrd"><H2>Byrd, William, 1543-1623</H2></A>
The second example could confuse your browser. Is it an anchor, formatted just like the text before it, with mysteriously placed heading tags, or is it a heading that also happens to be an anchor? If you use the right code in your HTML file, with the anchor inside the heading, you solve the confusion.
It's easy to forget about this, especially if you're like me and you create text first and then add links and anchors. It makes sense to just surround everything with an <A> tag. Think of it this way: If you were linking to just one word and not to the entire element, you'd put the <A> tag inside the <H2>. Working with the whole line of text isn't any different. Keep this rule in mind and you'll get less confused.
If you're still confused, Appendix B, "HTML Language Reference," has a summary of all the HTML tags and rules for which tags can and cannot go inside each one.
So you've added your anchor to the heading, and its name is "Byrd." Now go back to your M.html file, to the line with See Also.
Byrd, Gibbons, Lassus, Monteverdi, Morley, Weelkes, Wilbye</P>
You're going to create your link here around the word Byrd, just as you would for any other link. But what's the URL? As you learned in the previous section, pathnames to anchors look like this:
If you were creating a link to the to the B.html page itself, the HREF would be this:
Because you're linking to a section inside that page, add the anchor name to link that section, so that it looks like this:
Note the capital B in Byrd. Anchor names and links are case sensitive; if you put #byrd in your HREF, the link might not work properly. Make sure that the anchor name you used in the NAME attribute and the anchor name in the link after the # are identical.
A common mistake is to put a hash sign in both the anchor name and in the link to that anchor. The hash sign is used only to separate the page and the anchor in the link; anchor names should never have hash signs in them.
So, with the new link to the new section, the See Also line looks like this:
Gibbons, Lassus, Monteverdi, Morley, Weelkes, Wilbye</P>
And, of course, you could go ahead and add anchors and links to the other parts of the reference for the remaining composers.
With all your links and anchors in place, test everything. Figure 4.14 shows the Madrigals section with the link to Byrd ready to be selected.
Figure 4.15 shows what pops up when you select the Byrd link.
What if you have only one large page, and you want to link to sections within that page? You can use anchors for this, too, and for larger pages this can be an easy way to jump around within sections. All you need to do to link to sections is to set up your anchors at each section the way you usually would. Then, when you link to those anchors, leave off the name of the page itself, but include the hash sign and the name of the anchor. So, if you were linking to an anchor name called Section5 in the same page as the link, the link would look like this:
Go to <A HREF=#Section5>The Fifth Section</A>
When you leave off the page name, the browser assumes you are linking with the current page and will scroll to the appropriate section.
So far in this book you've encountered URLs twice-in Chapter 1, "The World of the World Wide Web," as part of the introduction to the Web, and in this chapter, when you created links to remote pages. If you've ever done much exploring on the Web, you've encountered URLs as a matter of course. You couldn't start exploring without a URL.
As I mentioned in Chapter 1, URLs are Uniform Resource Locators. URLs are effectively street addresses for bits of information on the Internet. Most of the time, you can avoid trying to figure out which URL to put in your links by simply navigating to the bit of information you want with your browser, and then copying and pasting the long string of gobbledygook into your link. But it's often useful to understand what a URL is all about and why it has to be so long and complex. Also, when you put your own information up on the Web, it'll be useful to know something about URLs so that you can tell people where your Web page is.
In this section, you'll learn what the parts of a URL are, how
you can use them to get
to information on the Web, and the kinds of URLs you can use (HTTP, FTP, Mailto, and so on).
Most URLs contain (roughly) three parts: the protocol, the host name, and the directory or filename (see Figure 4.16).
The protocol is the way in which the page is accessed; that is, the type of protocol or program your browser will use to get the file. If the browser is using HTTP to get to the file, the protocol part is http. If the browser uses FTP, it's ftp. If you're using Gopher, it's gopher, and so on. The protocol matches an information server that must be installed on the system for it to work. You can't use an FTP URL on a machine that does not have an FTP server installed, for example.
The host name is the system on the Internet where the information is stored, such as www.netcom.com, ftp.apple.com, or www.aol.com. You can have the same host name but have different URLs with different protocols, like this:
Same machine, three different information servers, and the browser will use different methods of connecting to that same machine. As long as all three servers are installed on that system and available, there's not a problem.
The host-name part of the URL may include a port number. The port number tells your browser to open a connection of the appropriate protocol on a specific network port other than the default port. The only time you'll need a port number in a URL is if the server handling the information has been explicitly installed on that port.
If a port number is necessary, it goes after the host name but before the directory, like this:
Finally, the directory is the location of the file or other form of information on the host. The directory may be an actual directory and filename, or it may be another indicator that the protocol uses to refer to the location of that information. (For example, Gopher directories are not explicit directories.)
A special character in a URL is anything that is not an upper- or lowercase letter, a number (0-9), or the following symbols: dollar sign ($), dash (-), underscore (_), period (.), or plus sign (+). Any other characters may need to be specified using special URL escape codes to keep them from being interpreted as parts of the URL itself.
URL escape codes are indicated by a percent sign (%) and a two-character hexadecimal symbol from the ISO-Latin-1 character set (a superset of standard ASCII). For example %20 is a space, %3f is a question mark, and %2f is a slash.
Say you had a directory named All My Files, probably on a Macintosh since there are spaces in the filename. Your first pass at a URL with that name in it might look like this:
http://myhost.com/harddrive/All My Files/www/file.html
If you put this URL in quotes in a link tag, it might work (but only if you put it in quotes). Because the spaces are considered special characters to the URL, though, some browsers may have problems with them and not recognize the pathname correctly. For full compatibility with all browsers, use %20:
Most of the time, if you make sure your file and directory names are short and use only alphanumeric characters, you won't need to include special characters in URLs. Keep this in mind as you write your own pages.
There are many kinds of URLs defined by the Uniform Resource Locator specification. (See Appendix A , "Sources for Further Information," for a pointer to the most recent version.) This section describes some of the more popular URLs and some things to look out for when using them.
HTTP URLs are the most popular form of URL on the World Wide Web. HTTP stands for HyperText Transfer Protocol and is the protocol that World Wide Web servers use to send HTML pages over the Net.
HTTP URLs follow the basic URL form:
If the URL ends in a slash, the last part of the URL is considered to be a directory name. The file that you get using a URL of this type is the "default" file for that directory as defined by the HTTP server, usually a file called index.html. (If the Web page you are designing is the top-level file for all the files in a directory, it's a good idea to call it index.html.)
You can also specify the filename directly in the URL. In this case, the file at the end of the URL is the one that is loaded.
It's also usually acceptable to use HTTP URLs like this, where foo is a directory:
In this case, because foo is a directory, this URL should have a slash at the end. Most Web servers are able to figure out that you meant this to be a directory and will "redirect" to the appropriate file. Some older servers, however, may have difficulties resolving this URL, so it's a good idea to always identify directories and files explicitly, and to make sure that a default file is available if you are indicating a directory.
FTP URLs are used to point to files located on FTP servers-and usually anonymous FTP servers; that is, those which you can log into using anonymous as the login ID and your e-mail address as the password. FTP URLs also follow the "standard" URL form.
Because you can retrieve either a file or a directory list with FTP, the restrictions on whether you need a trailing slash at the end of the URL are not the same as with HTTP. The first URL above retrieves a listing of all the files in the foo directory. The second URL retrieves and parses the file homepage.html in the foo directory.
Navigating FTP servers using a Web browser can often be much slower than navigating them using FTP itself, because the browser does not hold the connection open. Instead, it opens the connection, finds the file or directory listing, displays it, and then closes down the FTP connection. If you select a link to open a file or another directory in that listing, the browser will construct a new FTP URL from the items you selected, re-open the FTP connection using the new URL, get the next directory or file, and close it again. For this reason, FTP URLs are best when you know exactly which file you want to retrieve, rather than for browsing an archive.
Although your browser uses FTP to fetch the file, you still can get an HTML file from that server just as if it were an HTTP server, and it will parse and display just fine. Web browsers don't care how they get a hypertext file. As long as they can recognize it as HTML, either by the servers telling them it's an HTML file (as with HTTP-you'll learn more about this later), or by the extension to the filename, they will parse and display that file as an HTML file. If they don't recognize it as an HTML file, it's not a big deal; the browser can either display it if it knows what kind of file it is, or just save it to disk.
All the FTP URLs in the previous section were used for anonymous FTP servers. You can also specify an FTP URL for named accounts on an FTP server, like this:
In this form of the URL, the username part is your login ID on the server, and password is that account's password. Note that no attempt is made to hide that password in the URL. Be very careful that no one is watching you when you are using URLs of this form-and don't put them into a link that someone else can find!
File URLs are intended to reference files contained on the local disk. In other words, they refer to files that are located on the same system as the browser. For local files, file URLs take one of these two forms: the first with an empty host name (see the three slashes instead of two?) or with the hostname as localhost:
Depending on your browser, one or the other will usually work.
File URLs are very similar to FTP URLs, and in fact, if the host part of a file URL is not empty or localhost, your browser will try to find the given file using FTP. Both of the following URLs result in the same file being loaded in the same way:
Probably the best use of file URLs is in start-up pages for your browser (which are also called "home pages"). In this instance, because you will almost always be referring to a local file, a file URL makes sense.
The problem with file URLs is that they reference local files, where "local" means on the same system as the browser that is pointing to the file-not the same system that the page was retrieved from! If you use file URLs as links in your page, and then someone from elsewhere on the Net encounters your page and tries to follow those links, their browser will attempt to find the file on their local disk (and generally will fail). Also, because file URLs use the absolute pathname to the file, if you use file URLs in your page, you will not be able to move that page elsewhere on the system or to any other system.
If your intention is to refer to files that are on the same file system or directory as the current page, use relative pathnames instead of file URLs. With relative pathnames for local files and other URLs for remote files, there's no reason why you should need to use a file URL at all.
The Mailto URL is used to send electronic mail. If the browser supports Mailto URLs, when a link that contains one is selected, the browser will prompt you for a subject and the body of the mail message, and send that message to the appropriate address when you're done.
Some browsers do not support mailto and produce an error if a link with a Mailto URL is selected.
The Mailto URL is different from the standard URL form. It looks like this:
If your e-mail address includes a percent sign (%), you'll have to use the escape character %25 instead. Percent signs are special characters to URLs.
Gopher URLs use the standard URL file format up to and including the host name. After that, they use special Gopher protocols to encode the path to the particular file. The directory in Gopher does not indicate a directory pathname as HTTP and FTP URLs do and is too complex for this chapter. See the URL specification if you're really interested.
Most of the time you'll probably be using a Gopher URL just to point to a Gopher server, which is easy. A URL of this sort looks like this:
If you really want to point directly to a specific file on a Gopher server, probably the best way to get the appropriate URL is not to try to build it yourself. Instead, navigate to the appropriate file or collection using your browser, and then copy and paste the appropriate URL into your HTML page.
Usenet news URLs have one of two forms:
The first form is used to read an entire newsgroup, such as comp.infosystems. www.authoring.html or alt.gothic. If your browser supports Usenet news URLs (either directly or through a newsreader), it will provide you with a list of available articles in that newsgroup.
The second form enables you to retrieve a specific news article. Each news article has a unique ID, called a message ID, which usually looks something like this:
To use a message ID in a URL, remove the angle brackets and include the news: part:
Be aware that news articles do not exist forever-they "expire" and are deleted-so a message ID that was valid at one point may become invalid a short time later. If you want a permanent link to a news article, it is best to just copy the article to your Web presentation and link it as you would any other file.
Both forms of URL assume that you are reading news from an NNTP server. Both can be used only if you have defined an NNTP server somewhere in an environment variable or preferences file for your browser. Because of this, news URLs are most useful simply for reading specific news articles locally, and not necessarily for using in links in pages.
News URLs, like Mailto URLs, might not be supported by all browsers.
In this chapter, you learned all about links. Links are the things that turn the Web from a collection of unrelated pages into an enormous, interrelated information system (there are those big words again).
To create links, you use the <A>...</A> tag, called the link or anchor tag. The anchor tag has several attributes for indicating files to link to (the HREF attribute) and anchor names (the NAME attribute).
When linking pages that are all stored on the local disk, you can specify their pathnames in the HREF attribute as relative or absolute paths. For local links, relative pathnames are preferred because they let you move those local pages more easily to another directory or to another system. If you use absolute pathnames, your links will break if you change anything in that hard-coded path.
To link to a page on the Web (a remote page), the value of the HREF attribute is the URL of that page. You can easily copy the URL of the page you want to link. Just go to that page using your favorite Web browser, and then copy and paste the URL from your browser into the appropriate place in your link tag.
To create links to specific parts of a page, first set an anchor at the point you want to link to, use the <A>...</A> tag as you would with a link, but instead of the HREF attribute, you use the NAME attribute to name the anchor. You can then link directly to that anchor name using the name of the page, a hash sign (#), and the anchor name.
Finally, URLs (Uniform Resource Locators) are used to point to pages, files, and other information on the Internet. Depending on the type of information, URLs can contain several parts, but most contain a protocol type and location or address. URLs can be used to point to many kinds of information but are most commonly used to point to Web pages (http), FTP directories or files (ftp), information on Gopher servers (gopher), electronic mail addresses (mailto), or Usenet news (news).
|Q||My links aren't being highlighted in blue or purple at all. They're still just plain text.|
|A||Is the filename in an HREF attribute rather than in a NAME? Did you remember to close the quotes around the filename you're linking to? Both of these things can prevent links from showing up as links.|
|Q||I put a URL into a link, and it shows up as highlighted in my browser, but when I click on it, the browser says "unable to access page." If it can't find the page, why did it highlight the text?|
|A||The browser highlights text within a link tag whether or not the link is valid. In fact, you don't even need to be online for links to still show up as highlighted links, even though there's no way to get to them. The
only way you can tell if a link is valid is to select it and try to view the page that the link points to.
As to why the browser couldn't find the page you linked to-make sure you're connected to the network and that you entered the URL into the link correctly. Make sure you have both opening and closing quotes around the filename, and that those quotes are straight quotes. If you browser prints link destinations in the status bar when you move the mouse over a link, watch that status bar and see if the URL that appears is actually the URL you want.
Finally, try opening that URL directly in your browser and see if that works. If directly opening the link doesn't work either, there might be several reasons why. Two common ones are
|Q||Can I put any URL in a link?|
|A||You bet. If you can get to a URL using your browser, you can put that URL in a link. Note, however, that some browsers support URLs that others don't. For example, Lynx is really good with Mailto URLs (URLs that allow
you to send electronic mail to a person's e-mail address). When you select a Mailto URL in Lynx, it prompts you for a subject and the body of the message. When you're done, it sends the mail.|
Other browsers, on the other hand, may not handle Mailto URLs, and insist that a link containing the mailto URL is invalid. The URL itself may be fine, but the browser can't handle it.
|Q||Can I use images as links?|
|A||Yup. You'll learn how to do this in Chapter 7, "Using Images, Color, and Backgrounds."|
|Q||You've only described two attributes of the <A> tag: HREF and NAME. Aren't there others?|
|A||Yes; the <A> tag has several attributes including REL, REV, URN, METHODS, and TITLE. However, most of those attributes can be used only by tools that
automatically generate links between pages, or by browsers that can manage links better than most of those now available. Because 99 percent of you reading this book won't care about (or ever use) those links or browsers, I'm sticking to HREF and
NAME and ignoring the other attributes.
If you're really interested, I've summarized the other attributes in Appendix B, and there are pointers to the various HTML specifications in Appendix A, as well.
|Q||My links are not pointing to my anchors. When I follow a link, I'm always dropped at the top of the page instead of at the anchor. What's going on here?|
|A||Are you specifying the anchor name in the link after the hash sign the same way that it appears in the anchor itself, with all the uppercase and lowercase letters the identical? Anchors are case-sensitive, so if your browser cannot find an anchor name with an exact match, it may try to select something else in the page that is closer. This is dependent on browser behavior, of course, but if your links and anchors aren't working, it's usually because your anchor names and your anchors do not match. Also, remember that anchor names don't contain hash signs-only the links to them do.|
|Q||It sounds like file URLs aren't overly useful. Is there any reason you'd want to use them?|
|A||I can think of two. The first one is if you have many users on a single system (for example, on a UNIX system) and you want to give those local users (but nobody else) access to files on that system. By using file URLs
you can point to files on the local system, and anyone on that system can get to them. Readers from outside the system won't have direct access to the disk and wont be able to get to those files.|
A second good reason for using file URLs is that you actually want to point to a local disk. For example, you could create a CD full of information in HTML form, and then create a link from a page on the Web to a file on the CD using a file URL. In this case, because your presentation depends on a disk your readers must have, using a file URL makes sense.
|Q||Is there any way to indicate a subject in a Mailto URL?|
|A||Not at the moment. According to the current Mailto URL definition, the only thing you can put in a Mailto URL is the address to mail to. If you really need a subject or something in the body of the message, consider using a form instead (you'll learn more about forms on Day 9, "Creating Interactive Pages").|