Book HomeCascading Style Sheets: The Definitive GuideSearch this book Sunday 29th of March 2015 05:06:07 AM

9.4. Fixed Positioning

As implied in the previous section, fixed positioning is just like absolute positioning, except the containing block of a fixed element is always the viewport. In this case, the element is totally removed from the document's flow and does not have a position relative to any part of the document.

This can be exploited in a number of interesting ways. First off, it's possible to create frame-style interfaces using fixed positioning. Consider Figure 9-24, which shows a very common layout scheme.

Figure 9-24

Figure 9-24. Emulating frames with fixed positioning

This could be done using the following styles:

DIV#header {position: fixed; top: 0; bottom: 80%; left: 20%; right: 0;
background: gray;}
DIV#sidebar {position: fixed; top: 0; bottom: 0; left: 0; right: 80%;
background: silver;}

This will fix the header and sidebar to the top and side of the viewport, where they will remain regardless of how the document is scrolled. The drawback here, though, is that the rest of the document will be overlapped by the fixed elements. Therefore, the rest of the content should probably be contained in its own DIV and employ the following:

DIV#main {position: absolute; top: 20%; bottom: 0; left: 20%; right: 0;
overflow: scroll; background: white;}

It would even be possible to create small gaps between the three positioned DIVs by adding some appropriate margins, demonstrated in Figure 9-25:

BODY {background: black; color: silver;}  /* colors for safety's sake */

Figure 7-72

Figure 7-72. Floating an image wider than its parent element

Here, a left-floated image is wider than its parent, so its rightedge overruns the right edge of the parent element. Had the imagebeen floated to the right, then it would have overrun the left sideof the parent element instead.

7.6.1.3. No floating at all

DIV#header {position: fixed; top: 0; bottom: 80%; left: 20%; right: 0; background: gray; margin-bottom: 2px; color: yellow;} DIV#sidebar {position: fixed; top: 0; bottom: 0; left: 0; right: 80%; background: silver; margin-right: 2px; color: maroon;} DIV#main {position: absolute; top: 20%; bottom: 0; left: 20%; right: 0; overflow: scroll; background: white; color: black;}
Figure 9-25

Figure 9-25. Separating the "frames"

Given such a case, a tiled image could be applied to the BODY background. This image would show through the gaps created by the margins, which could certainly be widened if the author saw fit. For that matter, if a background image was of little importance, simple borders could be applied to the DIVs instead of margins.



Library Navigation Links

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

elements exist almost on their own plane, yet they still have major influence over the rest of the document.

Of course, when an element is floated, other content "flows around" it. This is familiar behavior with floated images, but the same is true if you float a paragraph, for example. In Figure 7-64, we can see this effect (a margin has been added to make the situation more clear):

P.aside {float: left; width: 5em; margin: 1em;}
Figure 7-64

Figure 7-64. A floating paragraph

As Figure 7-8 reveals, we have what we wanted. The order of the values is obviously important, and follows this pattern:

margin: top right bottom left
Figure 7-8

Figure 7-8. Uneven margins

A good way to remember this pattern is to keep in mind that the four values go clockwise around the element, starting from the top. The values are always applied in this order, so in order to get the effect you want, you have to arrange the values correctly.

  1. 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).
  2. 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).
  3. 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:

purposes. These lines would not actually appear in a web browser.

margin can accept any length measure, whether in pixels, inches, millimeters, or ems. However, the default value for margin is effectively 0 (zero), which means that if you don't declare a value, then by default, there won't be a margin.

TIP

In practice, browsers come with pre-assigned styles for many

yes

Applies to

all elements

heightIE4 Y/Y IE5 Y/Y NN4 N/N Op3 Y/-

This is usedto set the height of an element. Height is most often applied toimages, but can be used on any block-level or replaced element,although support for such behavior is not widespread as of thiswriting. Negative length values are not permitted.