This chapter is about writing style sheets with style. By showing you case studies and how they are constructed, we hope to give you a sense of how CSS can be used to encode the visual presentation you want to achieve. Also, more importantly, if you follow the guidelines in this chapter your documents will behave well on a wide range of web devices. For example, they will scale gracefully from one screen size to another.
The foremost tool for writing scalable style sheets is the "em" unit, and it therefore goes on top of the list of guidelines that we will compile throughout this chapter: use ems to make scalable style sheets. Named after the letter "M", the em unit has a long-standing tradition in typography where it has been used to measure horizontal widths. For example, the long dash often found in American texts (--) is known as "em-dash" since it historically has had the same width as the letter "M". Its narrower cousin (-), often found in European texts is similarly referred to as "en-dash".
The meaning of "em" has changed over the years. Not all fonts have the letter "M" in them (for example Chinese), but all fonts have a height. The term has therefore come to mean the height of the font - not the width of the letter "M".
In CSS, the em unit is a general unit for measuring lenghts, for example page margins and padding around elements. You can use it both horizontally and vertically, and this shocks traditional typographers who always have used em exclusively for horizontal measurements. By extending the em unit to also work vertically, it has become a very powerful unit - so powerful that you seldom have to use other length units.
When used to specify font sizes, the em unit refers to the font size of the parent element. So, in the example above, the font size of the h1 element is set to be two times the font size of the body element. In order to find what the font size of the h1 element will be, we need to know the font size of body . Since this isn't specified in the the style sheet, the browser will have to find it from somewhere else - a good place to look is in the user's preferences. So, if the user has set the normal font size to be 10 points, the size of the h1 element will be 20 points. This will make document headlines stand out relative to the the surrounding text. Therefore: always use ems to set font sizes.
Designers who come from desktop publishing may be inclined to skip the indirection that em introduces and specify directly that the font size should be 20 points. This is possible in CSS (see the description of the font-size property) but using "em" is a better solution. Say, for example, that a sight-impaired user sets his normal font size to 20pt (20 points). If the font size of H1 is 2em - as we recommend - h1 elements will scale accordingly and be displayed in 40 points. If, however, the style sheet sets the font size to be 20pt , there will be no scaling of fonts and the size of headlines will have the same size as the surrounding text.
The usefulness of the em unit isn't limited to font sizes. Figure 1 shows a page design where all lengths - including the padding and margins around elements - are specified in ems.
Let's first consider the padding. In CSS, padding is space around an element which is added to set the element apart from the rest of the content. The color of the padding is always the same as the background color of the element is surrounds. In figure 1 , the menu on the right has been given a padding with this rule:
By specifying the padding width in ems, the width of the padding is relative to the font size of the div element. As a designer, you don't really care what the exact width of the padding is on the user's screen, what you care about is the proportions of the page you are composing. If the font size of an element increases, the padding around the element should also increase. This is shown in figure 2 where the font size of the menu has increased while the proportions remain constant. (You can learn more about padding in chapter 9 .)
Outside the menu's padding is the margin area. The margin area ensures that there is enough space around an element so that the page doesn't appear cramped. The margin around the menu is set with this rule:
Figure 2 identifies the margin area. Again, the use of ems ensures scalable designs.
So, if ems are so great, why does CSS have other units as well? There are cases when it makes sense to use other units. E.g. , here is a case where percentages may work just as well, if not better: setting the margins of the body element. Remember that everything that is displayed in an HTML page is inside body , so setting the margins of that element sets the overal shape of the page. You could give the page nice wide margins on both sides with these two rules:
This makes the text 75 % of the total width, and the left margin a bit wider than the right one. Try it! Your page immediately looks more professional. Percentage values set on the body element will typically be caculated with respect to the browser window. So, in the example above, the text will cover 75 % of the browser window.
Both ems and percentages are relative units - which means they are computed with respect to something. We can distill a general rule from this: use relative units for lengths . But, how about the absolute units in CSS - inches, centimeters, points, pica - why are they in there at all if you never recommend their use?
There are cases when they should be used. Say, for example, that you are doing your wedding invitations using XML and CSS. You have carefully crafted tags such as <BESTMAN> and <RSVP/> and you plan to distribute the invitations through the Web. However, parts of your families are not yet connected and require printed invitations. On handmade paper, of course. With proper margins. And 12-point fonts, exactly. This is the time for pulling out the obsolete, ehhº absolute length units: only use absolute length units when the physical characteristics of the output medium are known . In practice, this only happens when you hand-tailor a style sheet for a specific printer paper size. In all other cases you are better off using relative length units.
A common presentation on the Web is to move element to the sides of the page. Typically, this is achieved by using a table for layout purposes. Although you can use CSS to describe table layout (see chapter 12 ), there is also a simpler way to "put stuff on the side." Floating elements slide over to the side of a page while allowing other content to "wrap around" it. The menu in figure 1 is an example of a floating element that has been set to float to the right side of the page. There are two steps to achieving this effect. First, the element must be declared to be floating using the float property. Second, the element must be prohibited from stretching out horizontally to fill the whole page. This is done through the width property. Here are the two rules needed:
By using floating text elements instead of tables, your markup can remain simple while achieving many of the visual effects which are often accomplished with tables in HTML. Thus, we have another guideline: use floating elements instead of tables . Simpler markup isn't the only reason why floating elements are good replacement for tables. Flexible layout schemes is another. By changing a few lines in the style sheet which generated the page in figure 1 we can, for example move the menu to the left side. See figure 3. Also, many text-only browsers have problems displaying tables since content within the table doesn't come in its logical order.
This brings us to the next guideline: put content in its logical order . Even though CSS allows you to move text around on the screen by means of floats and other ways of positioning, you should not rely on that. By putting content in its logical order you ensure that you document will make sense in browsers which don't support CSS. That includes browsers that work in text-mode, such as Lynx, older browsers, that date from before CSS, browsers whose users have turned style sheets off, or browsers that don't work visually at all: voice browsers and Braille browsers. Voice browsers may actually support CSS, since CSS can also describe the style of spoken pages, but aural CSS (see chapter [??]) doesn't allow text to be spoken out of order.
And even a browser that supports CSS may sometimes fail to load the style sheet, due to a network error. Therefore, you should always: make sure your documents are legible without style sheets . Legible to humans, but also to Web robots and other software, that tries to index, summarize, or translate your documents. And think of the future: in 5 years from now the style sheet may have gotten lost, in 50 years there may not be a browser that knows CSS anymore, and in 500 yearsº
A good way to make sure your documents are really legible is to: test your documents on several browsers . Alas, not all browsers which claim to support CSS do so according to W3C's specification. How much efforts you should put into testing you style sheets depends on the target audience of your documents. If you publish on a closed intranet where everyone uses the same browser, your testing job will be easy. If, on the other hand, your documents are openly available on the Web, testing can be a time-consuming task. One way to avoid doing all the testing yourself is to use one of the W3C Core Styles which are freely available on the Web (see chapter 19 ).
Realize that your document will end up on systems that have different fonts. CSS specifies five so-called generic fonts which are guaranteed to exist in all browsers: serif , sans-serif , monospace , cursive and fantasy . When specifying a font families in CSS you have the option of supplying a list to increase the chance of finding a specified font at the user's system. The last font family in the list should always be a generic font. So: always specify a fallback generic font . This book, e.g. , has been set in "Gill Sans." But not everybody has a copy of that font, so we actually specified the font as
which says that the font for the document's body is "Gill Sans" when available, or any other sans-serif font, when not. Depending on your browser and your machine's configuration, you may get Helvetica, or Arial, or something similar. You can learn more about setting fonts in chapter 6 .
Color names also vary from one platform to another. CSS supports 16 color names: aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, yellow, white. Some browsers have chosen to support additional color names, but there is no definite list. Therefore, you should: use numbers, not names, for colors . Color names may seem friendlier than the somewhat cryptic RGB notation introduced in the previous chapter, but the Web has yet to see the ultimate list of color names that work on all platforms. Color numbers, on the other hand, can easily be interpreted by any browser.
You may have to experiment a bit, to get the exact color you want, or find some software that helps you mix the right colors. CSS supports the hexadecimal notation ("#FF0000" and "#F00") and also some other notations that may be easier to use. The following two rules both set the color of h1 elements to brown (50% red, 50% green, 0% blue):
You can learn all about colors in chapter 13 .
A word of warning at the end: know when to stop . Be critical when designing your style sheet. Just because you can use 10 different fonts and 30 different colors on the same page doesn't mean you have to - or should. Simple style sheets often will convey your message better than overloaded ones. That single word of red in a page of black gets much more attention then any of the words on a page with a dozen different fonts and colors. If you think a piece of your text deserves more attention, try giving it larger margins, maybe even on all on all four sides. A little extra space can do wonders