Friday 20th of April 2018 08:24:17 AM

Book Home

Cascading Style Sheets: The Definitive GuideSearch this book

Symbols | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

Index: U

U element: 4.1.6. Text Decoration
UA (see user agent)
underlining: 4.1.6. Text Decoration
changing color of: 4.1.6.1. Weird decorations
removing from hyperlinks: 4.1.6. Text Decoration
turned off by browsers: 4.1.6.1. Weird decorations
Uniform Resource Identifier (URI): 3.5. CSS2 Units
Uniform Resource Locators (see URLs)
units: 11.1.3. Case 3: Putting a Magazine Article Online
(see also length units; CSS2 units)
for aural style sheets: 3.5. CSS2 Units
  • 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:

    universal selector: 10.2.1.1. Universal selector
    unordered lists: 7.7.1. Types of Lists
    unvisited anchors: 2.4.1. Pseudo-Class Selectors
    uppercase text: 4.1.5. Text Transformation
    upright text: 5.4.1. Fonts with Style
    URI (Uniform Resource Identifier): 3.5. CSS2 Units
    URLs (Uniform Resource Locators): 3.4. URLs
    HREF attribute and: 1.4.1.1. LINK attributes
    referring to in style sheets: 3.4. URLs
    specifying for images: 6.2.1. Background Images
    user agent (UA): 2.2.2. Grouping Declarations
    2.2.2. Grouping Declarations
    (see also browsers)
    users, selecting alternate style sheets: 1.4.1.2. Alternate style sheets


    Symbols | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z


    Library Navigation Links

    Copyright © 2002 O'Reilly & Associates, Inc. All Rights Reserved.

    background-image is not inherited -- in fact, none of the background properties are inherited. Remember also that when specifying the URL of a background image, it falls under the usual restrictions and caveats for url values: a relative URL should be interpreted with respect to the style sheet, but Navigator 4.x doesn't do this correctly, so absolute URLs may be a better answer.

    hasn't been violated, because the values of the seven properties add up to the required total. It's a semantic dodge, but it's valid behavior.

    Let's consider another example, illustrated in Figure 8-20, where the left margin is set to be negative:

    DIV {width: 400px; border: 1px solid black;}
    P.wide {margin-left: -50px; width: auto; margin-right: 10px;
    border: 3px solid gray;}
    Figure 8-20

    Figure 8-20. Setting a negative left margin

    Figure 4-56

    Figure 4-56. Transforming an H1 element in a different

    4.1.6. Text Decoration

    Finally,we come to text-decoration, which is a fascinatingproperty that carries along a whole truckload of oddities andinconsistencies in browsers. First, however, let's talk abouthow it should work in theory.