If you don't set a large enough line-height to accommodate the border, it will be in danger of overwriting other lines, as shown in Figure 8-62.

Figure 8-62

Figure 8-62. Inline borders can be overlapped

One solution is to increase the line-height of the paragraph. This will affect every line in the entire element, not just the line in which the bordered hyperlink appears:

A:link {border: 5px solid blue;}

Book HomeCascading Style Sheets: The Definitive GuideSearch this book
Wednesday 24th of August 2016 03:39:06 PM


10.6. Borders

In CSS1, there are quite a few properties devoted to setting borders around element boxes, such as border-top-width and border-color, not to mention border itself. CSS2 adds a even more border properties, most of which are aimed at giving the author even more specific control of the borders. Before, it was difficult to set a specific color or style for a given side of the border, except through properties like border-left, and that could require more than one value. The new CSS2 properties address this, and their names are pretty self-explanatory:

border-top-color
border-right-color
border-bottom-color
border-left-color
border-top-style
border-right-style
border-bottom-style
border-left-style


Library Navigation Links

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

7.5.2. Single-Side Padding

You guessed it: there are properties that let you set thepaddingon a single side of the box, without affecting the other sides.

padding-top, padding-right, padding-bottom, padding-left

that, it's easiest to turn to Figure 5-24, which illustrates the differences very clearly.

Figure 5-24

Figure 5-24. Italic and oblique text in detail

Basically, italic text is in some way its own font, with small changes made to the structure of each letter to account for the altered appearance. This is especially true of serif fonts, where in addition to the fact that the text characters "lean," the serifs may be altered in an italic face. Oblique text, on the other hand, is simply a slanted version of the normal, upright text. Font

  • 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:

    • You can generate the XML yourself (from your object model). If you created an object model that simply imports information from your XML document (using SAX or DOM), you would have to write a class that would convert your object model into an XML file (or set of XML files). This class would have to create an ApplicationML file that contains the information in your Java object model (which is in memory). Since this object model is not an adapter on top of DOM, it is not possible to use the DOM parser to generate the XML for you.