Book HomeCascading Style Sheets: The Definitive GuideSearch this book Thursday 28th of July 2016 10:33:17 AM

Chapter 10. CSS2: A Look Ahead


Changes from CSS1
CSS2 Selectors
Fonts and Text
Generated Content
Adapting to the Environment
Media Types and @-rules

In the course of writing this book, I vacillated back and forth over how to handle CSS2. It's a full W3C Recommendation, of course, but so little of it has actually been implemented correctly that it seemed almost a waste of time -- both mine and yours -- to talk about CSS2 in detail. After all, not only would I have to fake all of the screenshots (not to mention guess at correct behavior in a few cases), but you wouldn't be able to try out anything I discussed, since browsers wouldn't recognize your CSS2 rules.

On the other hand, CSS2 can hardly be ignored. So in the end, I settled on writing a chapter that talks about CSS2 in brief, abstract detail -- in other words, this chapter. The next edition of this book will almost certainly be driven by the need to add detailed information concerning CSS2, and will very likely be undertaken once the dust settles and browsers start to correctly implement major portions of CSS2.

Also realize that, of the figures shown in this chapter, the vast majority are -- well -- faked. There was no other way to produce most of these examples. The point of telling you this is to spare you the frustration of trying to figure out how they were produced. So, with that in mind, here's a brief taste of what CSS2 can offer.

10.1. Changes from CSS1

Only a few CSS1 properties have gained new values. These were mostly concerned with addressing issues that did not exist, or were not considered, when CSS1 was written. The one standout is a new value called inherit, which represents a huge change to everything -- but more on that in a moment.

10.1.1. Additions and Changes to the display Property

The property display has received quite a few new values in CSS2. Now, in addition to block, inline, line-item, and none, we have run-in, compact, and marker (which we'll get to later), as well as a number of values specific to tables (which we'll also cover later on).

The display value compact has an effect similar to <DL compact> (assuming your browser supports that bit of HTML). Basically, if an element is set to display: compact, then it will appear in the margin of the next element, assuming there is enough room for it. Otherwise, both elements will be treated as block-level elements. Think of a "compacted" element as one that floats, but only if there is room for it to be displayed without altering the formatting of the following element, something like the illustration in Figure 10-1.

Figure 10-1

Figure 10-1. Compact display of a definition list

On the other hand, run-in has the effect of turning a block-level element into an inline element at the beginning of the following block-level element. Another way to think of it is that a block-level element set to run-in will be combined with the next block-level element so that the two together form a single block-level element.

Given this code:

<H3 STYLE="display: run-in;">A Heading.</H3>
<P>This is a paragraph of text....</P>

the result will look something like what's shown in Figure 10-2.

Figure 10-2

Figure 10-2. A run-in heading

The display type run-in can be applied to any block-level element, not just headings. However, this rule should only work if the next element is block-level and is not floating or positioned absolutely. So, for example, if you try to set an inline anchor to run-in, it won't have any effect.

Another change for display is that its default value is inline, not block, as was defined in CSS1. The authors have termed the original default value an error, so if you don't declare a value for display, it is assumed to be inline. Of course, your browser should have its own built-in HTML styles, so don't worry about your paragraphs suddenly running together!

10.1.2. More Inheritance

Finally, there is one very important new feature of CSS2 that belongs in this section: the value inherit. If you were to ask the question, "Okay, to which properties did inherit get applied?" the answer would be, "Every last one of them." There is not a single property in the whole of CSS that does not accept a value of inherit.

inherit is used to explicitly declare that a given computed value should be inherited from its parent. In other words, if the font-size for BODY is computed to be 14 points, then the declaration P {font-size: inherit;} would set paragraph text to 14 points in size, as long as the paragraphs are children of the BODY element. Similarly, you could make sure that hyperlinks always have the same color as the text that surrounds them by using the simple declaration:

A:link, A:visited {color: inherit;}

The power of this change should not be underestimated. In effect, you are able to override the specificity mechanism that ordinarily takes effect. Usually, hyperlinks are (for instance) blue unless you explicitly declare them to be otherwise -- and if you want differently colored links in different areas of the same page, you'd have to construct a different rule for each color.

SPAN {border: 1px dashed black; padding: 4pt; margin: 8pt;}
Figure 8-60

Figure 8-60. Inline margins and line-box layout

8.4.3. Managing the Line Height of Inline Elements

In the previous section, we had a few cases where changing the line-height of an inline element led to the possibility of text from one line overlapping

Now, thanks to inherit, if it's okay to make them the same color as surrounding text, you just need one rule that will cover all circumstances. Note that I'm not saying this is a good idea, or the only thing for which inherit can be used. It's simply the most obvious possibility.

Library Navigation Links

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

green, and 98.6% blue. Not a problem:

H2 {color: rgb(25.5%,40%,98.6%);}

Actually, there is a problem. Some user agents may not recognize decimal values, and still others could interpret them as if the decimal wasn't there, which would lead them to think the preceding value is actually rgb(255%,40%,986%). In that case, assuming the user agent behaves correctly, the out-of-range values will be "clipped" to the nearest legal value -- in this case,only want part of it visible in the top left corner of the containingelement? No problem, at least in theory. First, assume the image is300 pixels tall by 300 pixels wide. Then, assume that only the bottomright third of it should be visible. We can get the desired effect(shown in Figure 6-45) like this:

BODY {background-image: url(bigyinyang.gif);background-repeat: no-repeat;background-position: -200px -200px;}
Figure 6-45

Figure 6-45. Using negative length values

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: