Introduction
Link concepts
Link basics
Links to remote resources
Links to local resources
Links using fragment identifiers
Other types of links
Images as links
Image maps
Hyperlinks (or just links
)put the
Web
in the World Wide Web. Each link
acts as a bridge from the page that contains it to another
Web resource. Typically, that other resource will be a
different Web page, but it might also be a number of other
types of resource, such as a file to be downloaded, an image
to be displayed, or even a different part of the same page.
This page was written to provide students in my CS403 class
with a simple sample document that demonstrates the use of
links that has been discussed in class. As with the other
sample documents I have provided, the primary motivation
has been to generate a relatively simple, but realistic,
document that not only reviews the concepts presented in
lecture, but also demonstrates their use in a
real world
situation.
To get the most out of this document, you should first read it and then study the source that the browser rendered in order to produce it. Use your browser’s ability to display the source of a document for this purpose.
A link is comprised of two anchors. The link is established by defining the source anchor, which can be thought of as the link’s starting point. Each link points to a single destination anchor, which is typically a different Web page but might also be any one of several types of resource. The destination anchor can be thought of as the link’s ending point. The direction of a link goes from its source anchor to its destination anchor.
Use the <a> element to insert a link into your Web
pages. The <a> element technically defines the link’s
source anchor, but through the value of its href
attribute it also specifies the destination anchor (and,
indirectly, the link’s direction).
A remote resource is any Web resource that is part of another Web presentation and therefore not under your direct control. Remote resources are generally stored on a different server host, and even when they are stored on the same server host as your presentation they are typically stored in a totally separate location in that host’s file system. As such, it’s impossible or impractical to use anything but an absolute URL to specify the location of a remote resource.
Therefore, when creating a link with a remote resource as its
destination anchor, always use an absolute URL as the value
of the <a> element’s href attribute.
Below are some examples of links to remote resources:
A local resource is any Web resource that is part of your Web presentation and therefore under your direct control. Local resources are generally stored on the same server host and typically in a nearby location within that host’s file system. As such, it’s generally best to use a relative URL any time you need to specify a local resource as the destination of a link.
In this course, I will expect all links to local resources to use
a relative URL as the value of their href attribute.
Below are some examples of links to local resources:
It is important to realize that whether a resource is local or remote is a matter of perspective. For example, while the above links are considered local to this presentation, they would need to be handled as links to remote resources in any Web pages you were to write.
A fragment identifier is an optional part of a URL that is used to specify a particular location within a Web page. Fragment identifiers always begin with a pound sign (#) and may appear either at the end of an absolute URL in order to specify a location within a remote resource or at the end of a relative URL to specify a location within a local resource. It is even acceptable to use a fragment identifier on its own as a form of URL to specify a location within the current document.
If you do not use a fragment identifier in a link, the browser assumes you intend to specify the top of the referenced page. But if you do use a fragment identifier in a link, the browser will try to display the specified location within the destination resource at the top of the browser window. This effectively allows you to create links that jump to a specific location within a page.
If the page is a remote resource, you have no control over its source code, so you may only reference the anchors that already exist within that page’s source. However, since you have complete control over your own source code, you can effectively create links to any spot in any of your local resources simply by establishing a valid destination anchor at that spot and using a fragment identifier for that destination anchor when you write the source anchor that defines the link.
To define a destination anchor, you can add an id attribute
to any XHTML element within the body of your document. The value of
that id attribute determines the identity of the destination
anchor. Note that all the id attributes within a single XHTML
document must have unique values and that those values should avoid spaces
and unusual
characters.
Although the vast majority of XHTML elements can accept an id
attribute for this purpose, it is actually rather common to use the <a>
element specifically for this purpose. In this case, the <a>
element is commonly used with an id attribute, but no
href attribute. Without an href attribute, the
<a> element does not define a link. If it has an id
attribute instead, it defines what is commonly called a named
anchor. Like any other element with an id attribute,
a named anchor can be used as the destination anchor of a link.
Links to named anchors and other identified elements can be very useful. For example, this document begins with a table of contents which you can jump to easily using the link just defined. If you examine the source code for this document, you will see that the table of contents consists of a series of links to identified heading elements throughout the page. This makes it very easy for a reader to jump directly to the portion of the document that interests them.
Since the table of contents itself begins with an identified header, it is very easy to establish links like the one that follows which allow the user to quickly return to the table of contents.
I have also embedded named anchors within the footer
and the middle of this page to allow the links within
this paragraph to take the user to those specific places. When examining the
source code for this page, note that the named anchor defined in the middle
of the page does not have any contents, while the one defined in the footer
does. This is to illustrate that contents are optional for the <a>
element, and that when they are present the browser does not render them
any differently than the surrounding text unless there is an href element
present.
When you follow a link to the footer, notice that the top of the footer does not go to the top of the browser window. In general, a browser will try to avoid showing empty space at the end of a Web page. As such, most browsers will not always show the destination anchor at the very top of the window, but rather as close to the top of the window as they can without forcing empty space to appear at the end of the document.
Also, if you follow a link, such as this one, whose destination anchor is very close by within the document source, you may well find that your browser does nothing since there is not much point in scrolling the window if it’s not really necessary.
It is also possible (and fairly common) to use a fragment identifier to reach a specific destination anchor in another page. To accomplish this, simply determine the URL that you would use to reach that page normally, and add the fragment identifier for the desired destination anchor to the end of it. Be careful to use a pound sign (#) between the file name and the identifier, and not a slash (/). And remember the fragment identifier must match the id value of the destination anchor exactly, in both spelling and case. Below are some sample links to specific destination anchors on other pages of the course Web site:
Useful links to CSS resources
A note on final grades
The policy on late submissions
Like images, links can pose difficulty for users with disabilities. As such, accessibility can be a concern. There are three tools that you might use to improve the accessibility of your links.
An <a> element may accept a title attribute, the value
of which is text that can be read aloud by a screen reader or otherwise
employed by a browser as a source of additional information about the link.
Consider the following examples:
Examine these links closely in different browsers. Do they appear any
differently than they did earlier on this page now that they all have
title attributes? What happens if you point at them with
the mouse without clicking?
An <a> element may also accept an accesskey attribute,
the value of which should be a single character. This allows browsers to
associate a key on the keyboard with that link for the user to employ as
a shortcut. Activation of links using access keys differs from browser to
browser, but under Windows it commonly involves holding down the Alt key
as you press the shortcut key. Try it out with some different browsers
using the following links:
Note that these links explicitly mention the shortcut key combination as part of the link label text. This is not strictly necessary, but it helps the user realize which links have shortcuts and what those shortcuts are.
Finally, an <a> element may accept a tabindex attribute,
the value of which should be an integer in the range 0 to 32767. This allows
browsers to support the use of the Tab key on the keyboard to select the links
on a page in the order you indicate. In supporting browsers, the Tab key should
select links with lower tabindex values first. Try it out with
some different browsers using the following links (you may have to hit the Tab
key several times to tab through all the other links and the various parts of
the browser interface, but when you do Tab to these links they should select
from the bottom of the list to the top):
While the vast majority of links will point to other Web pages, other types of links are available. Consider the following link, which leads to an image:
If you examine the source code, you’ll see that it is a link like any other except that it specifies a JPEG file as its destination rather than an XHTML file. This is meant simply to show that it is possible to link directly to an image. In general, however, you will instead want to link to an XHTML file that displays the image, since that will give you far more control over how the image is displayed and what accessibility considerations you apply.
It is also possible to create a link that can be used to send an e-mail message from any browser that has a built-in mail client. Try the following link for an example:
If you examine the source code, you’ll see that the main difference
between this link and the others on this page is that the URL consists of
mailto: as the scheme and my e-mail address as the identifier.
It is the e-mail address in the href attribute’s value that
determines where the browser’s mail client sends the message. The other
two occurrences of the e-mail address (in the title attribute’s
value and the contents of the <a> element) are provided as a convenience
to the user. The title attribute is provided to enhance accessibility,
and the contents of the <a> element are all that would be visible to the
user if they are using a Web browser without a built-in mail client or using
a printed version of the page.
Although many links use text as their label, it is also fairly common to use images as link labels. Doing so is simply a matter of nesting the <img /> element inside the <a> element that defines the link. This approach gives you a great deal of flexibility, since it means you can combine one or more images and/or text to create whatever link label makes sense for your page. Consider the following example where you may click either on the photo or the text to go to the sample document for images:
In studying the source code, notice that there is nothing special about either the <a> element or the <img /> element; both are written as they would be normally. All that is different from other examples is that within the <a> element is nested the <img /> element.
Also note that there is a minor difference in how this image is rendered. When an image is used as part of a link label, most browsers will place a border in the link color around the image. If this border is not desirable, it is possible to use CSS to remove the border.
An image map is a single image that contains one or more clickable "hotspots." Each hotspot acts like a link and may have its own destination anchor.
An image that acts as an image map gets inserted into your XTHML with an <img />
element just like any other image. However, to make it into an image map, it must
have a usemap attribute. The usemap attribute gets set
equal to the identifier of the image map to be used (preceded by a pound sign).
The image map to be used must be created elsewhere within the <body> using
a <map> element. The <map> element takes an id attribute,
the value of which establishes an identity for the image map and gets used in
the usemap attribute of the <img /> element. For maximum
compatibility with all browsers, it’s advisable to include the deprecated
name attribute in the <map> element as well. Be sure,
however, that both the name and id attributes have
exactly the same value.
Within the <map> element, a separate <area /> element is used to
define each hotspot. The <area> element accepts an href
attribute that specifies the URL of the destination anchor for that hotspot.
It also accepts an alt attribute that provides a textual
alternative for the hotspot. To define which area of the image the hotspot
occupies, the <area> element also accepts a shape
attribute (to determine the overall shape) and a coords
attribute (to determine the specific location and size of the hotspot.
Consider the following example:
