Publishers of technology books, eBooks, and videos for creative people

Home > Articles

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

Specific Challenges and Techniques

Throughout the rest of the book, we'll cover various development techniques that make heavy use of CSS. But here we'll touch on a number of very common CSS challenges that don't get much coverage elsewhere.

Styling Forms

Using CSS to style form elements has long caused developers headaches. In the past, support for styling form elements in many browsers was patchy, to say the least, and although contemporary browsers support CSS on form elements much better, there are problems stemming from the CSS specification and a lack of clarity about how form elements should be styled in some respects. Eric Meyer, whose knowledge of CSS is virtually without peer, has written on the issue extensively at meyerweb.com/eric/thoughts/2007/05/15/formal-weirdness.

This is not to say that developers shouldn't use CSS with form elements, but we should be aware of some of the potential problems and pay particular attention to cross-browser problems, since different browsers interpret the relevant CSS specification in different ways.

Image Replacement

Because of the limited range of fonts available via CSS prior to the widespread availability of downloadable fonts (an issue discussed in Chapter 15), web designers have long used images of text, particularly for headings and other display elements. Initially, this involved simply using an img element with the "text" of the heading or other element rendered as an image. This severely impacts both accessibility and search engine visibility, and so it is strongly advised against. After CSS became widely supported in browsers, designers developed a number of "image replacement" techniques that aimed to address these shortcomings, while still enabling the use of text as an image. The first generation of these techniques exemplified by FIR (the Fahrner Image Replacement Technique named after Todd Fahrner, its inventor) were based on the idea of placing the text of an image to be replaced inside a span element, and then hiding this text from the reader, while using an image with the text rendered on it via CSS as the background image for the element. So, for example, we'd have this HTML:

<h1 id="mainheading"><span>This is the text of the heading</span></h1>

We would then hide the text in the span, typically by positioning it absolutely and then giving it a large negative left value (some versions of the technique used display: none, which may hide the element from a screen reader). We then add a background image to the heading, which contains an image of the text we have hidden:

h1.mainheading {
  background-image: url("./images/mainheading.png");
  background-repeat: none;
}

h1.mainheading span {
  position: absolute;
  left: -1000px
}

Although this "solves" the problem by letting developers use fonts other than those available on the end user's system for a web page, and still provides text that a screen reader or search engine can recognize, it has several drawbacks:

  • The text won't increase or decrease in size when users zoom their text.
  • With screen magnifiers, the text will pixilate, rather than magnify smoothly as "real" text will.
  • Users often look for key words like "contact" on a page using the browser's find command, and image replacement can interfere with that.
  • The font is very likely rendered with a different font rendering engine than that found in the browser, and so there's a mismatch in terms of anti-aliasing and other font hints between the text in the image and other text on the page.
  • Site maintenance and development is more complicated, as any change to the text in replaced elements requires creating and uploading new images.

A second generation of techniques, typified by Scalable Inman Flash Replacement (sIFR), used Flash rather than images to replace the text. This addressed issues like magnification and zooming, but the other problems remain.

An even newer solution is Cufón (wiki.github.com/sorccu/cufon/about), which uses native browser technologies like SVG and VML—which we cover in Chapter 16—and JavaScript instead of Flash or images.

Despite their challenges, these techniques have been widely used, in part because clients and other decision makers often insist on a particular font being used. With luck, the arrival of widespread font embedding technology, which is covered in Chapter 15, will bring about an end to the need for these techniques.

Page Layout

As mentioned, we devote the whole of Chapter 9 to current practices in using CSS for page layout, so while we haven't touched on how to create multi-column layouts here, we'll cover that in detail there.

Browser Challenges

It's no secret that browser support for CSS for many years left quite a bit to be desired. Even though CSS support in all contemporary browsers is excellent, we'll still be dealing with legacy browsers like IE 6 for some time to come. In Chapter 7, we focus on the challenges of older browsers and techniques for addressing them.

Formatting CSS

In CSS code, whitespace isn't significant, which means we can use spaces, tabs, and returns to improve the legibility of our CSS. Some common techniques for making CSS more readable include:

  • Separating the selector from the declaration block with a return
  • Putting each declaration on a new line and indenting them with a tab
  • Ordering declarations alphabetically by property name

An example statement using these techniques might look like this:

p {
  border: solid thin #555;
  color: #333;
  font-family:
"Lucida Sans Unicode", "Lucida Grande", sans-serif;
  line-height: 1.3;
  padding: 1em
}

CSS and Site Performance

When using CSS, as with any external resource (images, scripts, and so on), two things can impact the performance of a site: the size of the file, and the number of linked files. While CSS files are typically small in comparison with external resources like images, we can optimize them by removing all whitespace and comments and by using shorthands. Of course, these all make your code far less legible and less maintainable, so rather than using these techniques in your development code, it's best to process your CSS into a production version just before serving it. There are numerous CSS compression tools available, with a good list here: www.askapache.com/css/online-css-compression-tools.html.

The other main impact on site performance is the number of external linked files. For production code, it can help to move numerous individual style sheets into a single large style sheet before serving.

Both of these are things that can help improve the performance of heavily trafficked sites, if you find page load times are less than desired.

  • + Share This
  • 🔖 Save To Your Account