The difference between a and a:link

Many designers don’t realize the difference between the selectors a and a:link in CSS.
Essentially, the a selector styles all anchors, but a:link styles only those that are clickable
links (i.e., those that include an href attribute) that have not yet been visited. This means
that, should you have a site with a number of fragment identifiers, you can use the a:link
selector to style clickable links only, avoiding styling fragment identifiers, too. (This prevents
the problem of fragment identifiers taking on underlines, and also prevents the
potential problem of user-defined style sheets overriding the a rule.) However, if you
define a:link instead of a, you then must define the visited, hover, and active states,
otherwise they will be displayed in their default appearances. This is particularly important
when it comes to visited, because that state is mutually exclusive to link, and doesn’t
take on any of its styling. Therefore, if you set font-weight to bold via a:link alone, visited
links will not appear bold (although the hover and active states will for unvisited
links—upon the links being visited, they will become hover and active states for visited
links and will be displayed accordingly).

Web Navigation types

Inline navigation: General links within web page content areas
Site navigation: The primary navigation area of a website, commonly referred to as
a navigation bar
Search-based navigation: A search box that enables you to search a site via terms
you input yourself

Inline navigation
Inline navigation used to be the primary way of navigating the Web, which, many moons
ago, largely consisted of technical documentation. Oddly, inline navigation—links within a
web page’s body copy—is less popular than it once was. Perhaps this is due to the increasing
popularity of visually oriented web design tools, leading designers to concentrate more
on visuals than usability. Maybe it’s because designers have collectively forgotten that links
can be made anywhere and not just in navigation bars. In any case, links—inline links in
particular—are the main thing that differentiates the Web from other media, making it
unique. For instance, you can make specific words within a document link directly to
related content. A great example of this is Wikipedia (www.wikipedia.org), the free encyclopedia.

 

Site navigation
Wikipedia showcases navigation types other than inline. To the left, underneath the logo,
is a navigation bar that is present on every page of the site, allowing users to quickly access
each section. This kind of thing is essential for most websites—long gone are the days
when users often expected to have to keep returning to a homepage to navigate to new
content.
As Wikipedia proves, just because you have a global navigation bar, that doesn’t mean you
should skimp on inline navigation. In recent times, I’ve seen a rash of sites that say things
like, “Thank you for visiting our website. If you have any questions, you can contact us byclicking the contact details link on our navigation bar.” Quite frankly, this is bizarre. A better
solution is to say, “Thank you for visiting our website. If you have any questions, please
contact us,” and to turn “contact us” into a link to the contact details page. This might
seem like common sense, but not every web designer thinks in this way.

Search-based navigation
Wikipedia has a search box within its navigation sidebar. It’s said there are two types of
web users: those who eschew search boxes and those who head straight for them. The
thing is, search boxes are not always needed, despite the claims of middle managers the
world over. Indeed, most sites get by with well-structured and coherent navigation.
However, sites sometimes grow very large (typically those that are heavy on information
and that have hundreds or thousands of pages, such as technical repositories, review
archives, or large online stores, such as Amazon and eBay). In such cases, it’s often not feasible
to use standard navigation elements to access information. Attempting to do so leads
to users getting lost trying to navigate a huge navigation tree.
Unlike other types of navigation, search boxes aren’t entirely straightforward to set up,
requiring server-side scripting for their functionality. However, a quick trawl through
a search engine provides many options, including Google Custom Search Engine
(www.google.com/coop/cse/) and Yahoo Search Builder (http://builder.search.yahoo.
com/m/promo).

Backward compatibility with fragment identifiers

In older websites, you may see a slightly different system for accessing content within a
web page, and this largely involves obsolete browsers such as Netscape 4 not understanding
how to deal with links that solely use the id attribute. Instead, you’ll see a fragment
identifier, which is an anchor tag with a name attribute, but no href attribute. For instance,
a fragment identifier for the first answer is as follows:
<p><a id="answer1" name="answer1">Answer 1!</a></p>

The reason for the doubling up, here—using both the name and id attributes, is because
the former is on borrowed time in web specifications, and it should therefore only be used
for backward compatibility.

Internal page links

Along with linking to other documents, it’s possible to link to another point in the same
web page. This is handy for things like a FAQ (frequently asked questions) list, enabling the
visitor to jump directly to an answer and then back to the list of questions; or for top-ofpage
links, enabling a user single-click access to return to the likely location of a page’s
masthead and navigation, if they’ve scrolled to the bottom of a long document.
When linking to other elements on a web page, you start by providing an id value for any
element you want to be able to jump to. To link to that, you use a standard anchor element
(<a>) with an href value equal to that of your defined id value, preceded by a hash
symbol (#).
For a list of questions, you can have something like this:
<ul id="questions">
<li><a href="#answer1">Question one</a></li>
<li><a href="#answer2">Question two</a></li>
<li><a href="#answer3">Question three</a></li>
</ul>
Later on in the document, the first two answers might look like this:
<p id="answer1">The answer to question 1!</p>
<p><a href="#questions">Back to questions</a></p>
<p id="answer2">The answer to question 2!</p>
<p><a href="#questions">Back to questions</a></p>
As you can see, each link’s href value is prefixed by a hash sign. When the link is clicked,
the web page jumps to the element with the relevant id value. Therefore, clicking the
Question one link, which has an href value of #answer1, jumps to the paragraph with the
id value of answer1. Clicking the Back to questions link, which has an id value of
#questions, jumps back to the list, because the unordered list element has an id of
questions.

**NOTE : It’s worth bearing in mind that the page only jumps directly to the linked element if
there’s enough room underneath it. If the target element is at the bottom of the web
page, you’ll see it plus a browser window height of content above.

Using CSS to wrap text around images

You can use the float and margin properties to enable body copy to wrap around an
image. The method is similar to the pull quote example in the previous chapter, so we
won’t dwell too much on this. Suffice to say that images can be floated left or right, and
margins can be set around edges facing body copy in order to provide some whitespace.
For example, expanding on the previous example, you could add the following rules to
ensure that the surrounding body copy doesn’t hug the image:
.photo {
border-width: 8px 8px 20px 8px;
border-style: solid;
border-color: #ffffff;
float: right;
margin-left: 20px;
margin-bottom: 20px;
}

This results in the following effect shown in the following image.

 

See using-css-to-wrap-around-images.html, using-css-to-wrap-around-images.css,
and sunset.jpg in the chapter 4 folder for a working example of this page.

Using CSS when working with images

Applying CSS borders to images

Alternatively, you could set borders to be on by default, and override them in specific

areas of the website via a rule using grouped contextual selectors:

img {

border: 1px solid #000000;

}

#masthead img, #footer img, #sidebar img {

border: 0;

}

Finally, you could override a global border setting by creating a noBorder class and then

assigning it to relevant images. In CSS, you’d write the following:

.noBorder {

border: 0;

}

And in HTML, you’d add the noBorder class to any image that you didn’t want to have a

border:

<img class="noBorder" src="sunset.jpg" height="200" width="400"

å alt="A photo of a sunset" />

Clearly, this could be reversed (turning off borders by default and overriding this with, say,

an addBorder style that could be used to add borders to specific images). Obviously, you

should go for whichever system provides you with the greatest flexibility when it comes to

rapidly updating styles across the site and keeping things consistent when any changes

occur. Generally, the contextual method is superior for achieving this.

Although it’s most common to apply borders using the shorthand shown earlier, it’s possible

to define borders on a per-side basis, as demonstrated in the “Using classes and CSS

overrides to create an alternate pull quote” exercise in Chapter 3. If you wanted to style a

specific image to resemble a Polaroid photograph, you could set equal borders on the top,

left, and right, and a larger one on the bottom. In HTML, you would add a class attribute

to the relevant image:

<img class="photo" src="sunset.jpg" height="300" width="300"

å alt="Sunset photo" />

In CSS, you would write the following:

.photo {

border-width: 8px 8px 20px;

border-style: solid;

border-color: #ffffff;

}The results of this are shown in the image to the

right. (Obviously, the white border only shows if

you have a contrasting background—you wouldn’t

see a white border on a white background!)

Should you want to, you can also reduce the declaration’s

size by amalgamating the border-style

and border-color definitions:

.photo {

border: solid #ffffff;

border-width : 8px 8px 20px;

}

You may have noticed earlier that I didn’t mention the border attribute when working

through the img element. This is because the border attribute is deprecated; adding borders

to images is best achieved and controlled by using CSS. (Also, because of the flexibility

of CSS, this means that if you only want a simple surrounding border composed of flat

color, you no longer have to add borders directly to your image files.) Should you want to

add a border to every image on your website, you could do so with the following CSS:

img {

border: 1px solid #000000;

}

In this case, a 1-pixel solid border, colored black (#000000 in hex), would surround every

image on the site. Using contextual selectors, this can be further refined. For instance,

should you only want the images within a content area (marked up as a div with an id

value of content) to be displayed with a border, you could write the following CSS:

div#content img {

border: 1px solid #000000;

}

Common web image gaffes

Using graphics for body copy
Some sites out there use graphics for body copy on web pages, in order to get more typographical
control than CSS allows. However, using graphics for body copy causes text to
print poorly—much worse than HTML-based text. Additionally, it means the text can’t be
read by search engines, can’t be copied and pasted, and can’t be enlarged, unless you’re
using a browser (or operating system) that can zoom—and even then it will be pixilated. If
graphical text needs to be updated, it means reworking the original image (which could
include messing with line wraps, if words need to be added or removed), re-exporting it,
and reuploading it.
As mentioned in the “Image-replacement techniques” section of Chapter 3, the argument
is a little less clear-cut for headings (although I recommend using styled HTML-based text
for those, too), but for body copy, you should always avoid using images.

Not working from original images
If it turns out an image on a website is too large or needs editing in some way, the original
should be sourced to make any changes if the online version has been in any way compressed.
This is because continually saving a compressed image reduces its quality each
time. Also, under no circumstances should you increase the dimensions of a compressed
JPEG. Doing so leads to abysmal results every time.

Overwriting original documents
The previous problem gets worse if you’ve deleted your originals. Therefore, be sure that
you never overwrite the original files you’re using. If resampling JPEGs from a digital camera
for the Web, work with copies so you don’t accidentally overwrite your only copy of
that great photo you’ve taken with a much smaller, heavily compressed version. More
important, if you’re using an application that enables layers, save copies of the layered
documents prior to flattening them for export—otherwise you’ll regret it when having to
make that all-important change and having to start from scratch.

Busy backgrounds

When used well, backgrounds can improve a website, adding visual interest and atmosphere—
see the following image, showing the top of a version of the Snub
Communications homepage. However, if backgrounds are too busy, in terms of complicated
artwork and color, they’ll distract from the page’s content. If placed under text, they
may even make your site’s text-based content impossible to read. With that in mind, keep
any backgrounds behind content subtle—near-transparent single-color watermarks tend
to work best.
For backgrounds outside of the content area (as per the “Watermarks” section in Chapter 2),
you must take care, too. Find a balance in your design and ensure that the background
doesn’t distract from the content, which is the most important aspect of the site.

Lack of contrast
It’s common to see websites that don’t provide enough contrast between text content and
the background—for example, (very) light gray text on a white background, or pale text
on an only slightly darker background. Sometimes this lack of contrast finds its way into
other elements of the site, such as imagery comprising interface elements. This isn’t always
a major problem—in some cases, designs look stylish if a subtle scheme is used with care.
You should, however, ensure that usability isn’t affected—it’s all very well to have a subtle
color scheme, but not if it stops visitors from being able to easily find things like navigation
elements, or from being able to read the text.

Using the wrong image format
Exporting photographs as GIFs, using BMPs or TIFFs online, rendering soft and blotchy line
art and text as a result of using the JPEG format—these are all things to avoid in the world
of creating images for websites. See the section “Choosing formats for images” earlier in
this chapter for an in-depth discussion of formats.

Resizing in HTML
When designers work in WYSIWYG editing tools, relying on a drag-and-drop interface, it’s
sometimes tempting to resize all elements in this manner (and this can sometimes also be
done by accident), thereby compromising the underlying code of a web page. Where
images are concerned, this has a detrimental effect, because the pixel dimensions of the
image no longer tally with its width and height values. In some cases, this may lead to distorted
imagery (as shown in the rather extreme example that follows);

it may also lead to
visually small images that have ridiculously large files sizes by comparison. In most cases,
distortion of detail will still occur, even when proportion is maintained.

Not balancing quality and file size
Bandwidth can be a problem in image-heavy sites—both in terms of the host getting hammered
when visitor numbers increase, and in terms of the visitors—many of whom may be
stuck with slower connections than you—having to download the images. Therefore, you
should always be sure that your images are highly optimized, in order to save on hosting
costs and ensure that your website’s visitors don’t have to suffer massive downloads. (In
fact, they probably won’t—they’ll more than likely go elsewhere.)
But this doesn’t mean that you should compress every image on your website into a slushy
mess (and I’ve seen plenty of sites where the creator has exported JPEGs at what looks like
90% compression—“just in case”).
Err on the side of caution, but remember: common interface elements are cached, so you
can afford to save them at a slightly higher quality. Any image that someone requests
(such as via a thumbnail on a portfolio site) is something they want to see, so these too
can be saved at a higher quality because the person is likely to wait. Also, there is no such
thing as an optimum size for web images. If you’ve read in the past that no web image
should ever be larger than 50 KB, it’s hogwash. The size of your images depends entirely
on context, the type of site you’re creating, and the audience you’re creating it for.
There are exceptions to this rule, however, although they are rare. For instance, if you
work with pixel art saved as a GIF, you can proportionately enlarge an image, making
it large on the screen. Despite the image being large, the file size will be tiny.

Text overlays and splitting images
Some designers use various means to stop people from stealing images from their site and
reusing them. The most common are including a copyright statement on the image itself,
splitting the image into a number of separate images to make it harder to download, and
adding an invisible transparent GIF overlay.
The main problem with copyright statements is that they are often poorly realized (see the
following example), ruining the image with a garish text overlay. Ultimately, while anyone
can download images from your website to their hard drive, you need to remember that if
someone uses your images, they’re infringing your copyright, and you can deal with them
accordingly (and, if they link directly to images on your server, try changing the affected
images to something text-based, like “The scumbag whose site you’re visiting stole images
from me”).

As for splitting images into several separate files or placing invisible GIFs over images to try
to stop people from downloading them, don’t do this—there are simple workarounds in
either case, and you just end up making things harder for yourself when updating your
site. Sometimes you even risk compromising the structural integrity of your site when
using such methods.

Stealing images and designs
Too many people appear to think that the Internet is a free-for-all, outside of the usual
copyright restrictions, but this isn’t the case: copyright exists on the Web just like everywhere
else. Unless you have permission to reuse an image you’ve found online, you
shouldn’t do so. If discovered, you may get the digital equivalent of a slap on the wrist, but
you could also be sued for copyright infringement.