Book HomeCascading Style Sheets: The Definitive GuideSearch this book Thursday 26th of November 2015 11:29:17 AM

10.3. Fonts and Text

The font property has also picked up a few new values in CSS2:


These values give the font property the ability to match the font family, size, weight, and so forth, according to the settings users have specified on their computers. For example, icons on a Macintosh are typically labeled using 9-point Geneva. Assuming that hasn't been changed by the user, any font declaration with a value of icon will result in 9-point Geneva for that text -- as long as the page is viewed using a Macintosh:

SPAN.OScap {font: icon;}  /* will look like icon labels in OS */

On a Windows system, of course, the font would come out different, and under other window managers (like X), it would look different backgrounds of form elements.


Just like background-color,background-image is not inherited -- in fact,none of the background properties are inherited. Remember also thatwhen specifying the URL of a background image, it falls under theusual restrictions and caveats for url values: arelative URL should be interpreted with respect to the style sheet,but Navigator 4.x doesn't do this correctly, so absolute URLs still. The flexibility is certainly interesting, and it allows the author to easily create pages that have an appearance familiar to the user.

10.3.1. New Font Properties

The font section gains two new properties in CSS2. font-size-adjust is intended to help browsers make sure that text will be the intended size, regardless of whether the browser can use the font specified in the style sheet. It is often a problem that authors will call for a font that is not available to the user, and when another font is substituted, it's either too big or too small to read comfortably. This new property addresses that very problem, and should be very useful for authors who want to make sure that their documents are readable no matter what font is substituted.

The other new font property is font-stretch , which allows you to define variable widths for the fonts you use. This is similar to setting a character width in a desktop publishing system. The property uses keywords such as ultra-condensed , wider, and expanded. The changes are handled in a fashion similar to font weights, where a table of condensed and expanded font faces is constructed, and the keywords are assigned to various faces. If no face exists, the user agent may try to scale a font on its own, or it may simply ignore font-stretch altogether. Figure 10-13 shows what a font might look like for each possible value of font-stretch.

Figure 10-13

Figure 10-13. Stretching fonts

10.3.2. text-shadow

In terms of text, there is one new property, text-shadow, which has the effect you'd probably expect from its name: you can define a drop shadow of a given color for text. You can even set an offset and a blur radius, which means you can get cool fuzzy shadows, or even glow effects, using this property. We should fully expect to see this property horribly abused the instant it's supported by any browser; for a few examples of why, see the simulations in Figure 10-14.

Figure 10-14

Figure 10-14. Various effects using the text-shadow property

Library Navigation Links

Copyright © 2002 O'Reilly & Associates. All rights reserved.

rule that wins out will completely replace the value of the loser.Consider:

H2.stricken {text-decoration: line-through;}H2 {text-decoration: underline overline;}

Given these rules, any H2 element with a class ofstricken will have only a line-through decoration.The underline and overline decorations are lost, since shorthandvalues replace one another, instead of accumulating.

In order to successfully load an external style sheet, LINK must be placed inside the HEAD element but may not be placed inside any other element, rather like TITLE or STYLE. This will cause the web browser to locate and load the style sheet and use whatever styles it contains to render the HTML document, in the manner shown in Figure 1-2.

And what is the format of an external style sheet? It's simply a list of rules, just like those we saw in the previous section and<DIV> This first line of the DIV is indented by 50 pixels. <P>This paragraph is 200px wide, and the first line of the paragraph is indented 50px. This is because computed values for 'text-indent' are inherited, instead of the declared values.</P> </DIV>

Even though the paragraph is only 200 pixels wide, its first line is indented by 50 pixels (as Figure 4-9 shows), which is the inherited value for text-indent. Use DOM to directly manipulate the information stored in the document (which DOM turns into a tree of nodes). This document object is created by the DOM XML parser after it reads in the XML document. This option leads to messy and hard-to-understand code. Also, this works better for document-type data rather than just computer generated data (like data structures and objects used in your code).

  • Create your own Java object model that imports information from the XML document by using either SAX or DOM. This kind of object model only uses SAX or DOM to initialize itself with the information contained in the XML document(s). Once the parsing and initialization of your object model is completed, DOM or SAX isn't used anymore. You can use your own object model to accessed or modify your information without using SAX or DOM anymore. So you manipulate your information using your own objects, and rely on the SAX or DOM APIs to import the information from your ApplicationML file into memory (as a bunch of Java objects). You can think of this object model as an in-memory instance of the information that came was "serialized" in your XML document(s). Changes made to this object model are made persistent automatically, you have to deal with persistence issues (ie, write code to save your object model to a persistence layer as XML).
  • Create your own Java object model (adapter) that uses DOM to manipulate the information in your document object tree (that is created by the parser). This is slightly different from the 2nd option, because you are still using the DOM API to manipulate the document information as a tree of nodes, but you are just wrapping an application specific API around the DOM objects, so its easier for you to write the code. So your object model is an adapter on top of DOM (ie, it uses the adapter pattern). This application specific API uses DOM and actually accesses or modifies information by going to the tree of nodes. Changes made to the object model still have to be made persistence (if you want to save any changes). You are in essence creating a thin layer on top of the tree of nodes that the parser creates, where the tree of nodes is accessed or modified eventually depending on what methods you invoke on your object model.
  • Depending on which of the three options you use to access information using your Java classes, this information must at some point be saved back to a file (probably to the one from which it was read). When the user of your application invokes a File->Save action, the information in the application must be written out to an ApplicationML file. Now this information is stored in memory, either as a (DOM) tree of nodes, or in your own proprietary object model. Also note that most DOM XML parsers can generate XML code from DOM document objects (but its quite trivial to turn a tree of nodes into XML by writing the code to do it yourself). There are 2 basic ways to get this information back into an ApplicationML file: