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
Copyright © 2002 O'Reilly & Associates. All rights reserved.when viewed in a web browser, and it doesn't necessarily change the origin image's position as the window is resized. If the document width is fixed (perhaps by assigning an explicit width to the BODY element), then resizing the viewing area won't affect the placement of the origin image.
In technical terms, when a background image has been set to be fixed, it is text is already set to bold. If there is no bolder face available, then the user agent sets the weight of B text within an H1 to 800, since that is the next step up from 700 (the numeric equivalent to bold). Since 800 is assigned to the same font face as 700, there is no visible difference between normal H1 text and boldfaced H1 text, but nonetheless the weights are different.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: