Book HomeCascading Style Sheets: The Definitive GuideSearch this book Wednesday 13th of December 2017 08:03:50 PM

1.3. Limitations of CSS

There are a few areas that CSS1 does not address, and therefore are not covered in detail in this book; some of these topics are touched upon in Chapter 10, "CSS2: A Look Ahead". Of course, even a full-blown CSS implementation, covering all of CSS1 and CSS2, would not meet every request from every page designer in the world. It's worth going through some of the boundaries of CSS.

1.3.1. Limited Initial Scope

When you get right down to it, CSS1 is not an overly complicated specification. The entire thing can be printed out in less than 100 pages, and it contains about 70 properties. It is still a very sophisticated and subtle engine, but some areas of web design were omitted from CSS1.

In the first place,


<list-style-type> || <list-style-image> ||<list-style-position>

Figure 7-87

Figure 7-87. Bringing it all together

The values for list-style can be listed in anyorder, and any of them can be omitted. As long as one is present, therest will fill in their default values. For instance, the following CSS1 had almost nothing to say about tables. You might think that you can set margins on table cells, for example -- and a web browser might even let you do so -- but margins should not be applied to table cells under any circumstances. CSS2 introduced a new set of properties and behaviors for dealing with tables, but as of this writing, few if any of these are supported.


To a certain degree, the omission of tables from CSS1 says a great deal about the feeling many have that tables should never be used to lay out pages. It is felt that floated and positioned elements should do all of the work tables used to do, and more. Whether this premise can be supported is not a discussion I intend to undertake here.

In a similar way, CSS1 contains nothing in the way of positioning. Sure, it's possible to move elements around a little bit, but mostly with negative margins and floating. Everything is, in a sense, relative. CSS2, on the other hand, has three chapters devoted to the visual rendering model, which includes the positioning of elements.

CSS1 makes no provision for downloadable fonts. This leads to a good deal of discussion about how to account for user system configurations and available fonts. CSS2 introduces some font-handling, but even there the issue is not resolved, mostly due to the lack of a widely supported font format. It may be that Scalable Vector Graphics (SVG) will solve some or all of this problem, but it is impossible at this point to say with any certainty.

Finally, there is a lack of media types in CSS1. In other words, CSS1 is primarily a screen-device language, intended to be used to put content onto a computer monitor. There is some thought toward paged media, like printouts, but not much. (Despite this, CSS1 is not a pixel-perfect control mechanism.) In an effort to overcome this limitation, CSS2 introduces media types, which makes it possible to create separate style sheets that are applied to a document depending on its display media. CSS2 also introduces properties and behavior specifically aimed at paged media and aural media.

1.3.2. Implementations

Sadly, the major drawback to using CSS is that it was so poorly implemented at first. Through a combination of miscommunication, misinterpretation, confusion, and poor quality control, the first browsers to attempt support of CSS did a rather poor job of it.

The worst offenders are Microsoft Internet Explorer 3.x and Netscape Navigator 4.x. The first in their respective lines to attempt CSS support, these browsers have incomplete, bug-ridden, and quite often contradictory implementations of CSS1, never mind CSS2. These implementations are so bad that it is difficult to consider them CSS-supporting at all. Some of their flaws are bad enough to cause the browser to crash, or even lock up an entire system, when trying to handle some styles.

With Internet Explorer 4.x and 5.x, things did improve. Although not perfect by any means, these browser versions did at least stomp out many of the bugs that plagued IE3, and also added some support for previously unrecognized CSS properties in both CSS1 and CSS2.

Opera 3.5, on the other hand, came out of the gate with impressive CSS support. Confining itself to CSS1, this browser did quite well with the properties that it supported, suffering only a few minor bugs. When 3.6 was released, almost all of these bugs were eliminated, although support did not move past CSS1. Before version 3.5, Opera did not support CSS at all.

As for Netscape's products, the Navigator 4.7 is not significantly better at CSS support than was version 4.0, although it's at least less crash-prone. The only real hope for good CSS support out of Netscape is their Gecko rendering engine. As this was being written, the latest builds of Gecko were quite excellent, and were in fact used (along with Internet Explorer 4.5 and 5.0 for Macintosh) to create many of the figures in this book.

Since CSS is not intended to provide total control over document display, and should allow the page's content to come through no matter what browser is being used, this general state of affairs should not be considered a barrier to the use of CSS. You may wish, however, to warn your users that if they are using browsers of a certain vintage (Explorer 3.x, and perhaps Navigator 4.x) that they go into their preferences and disable style sheets. That way, they'll at least be able to read the content of your pages, even if it isn't styled the way you might have hoped.

Library Navigation Links

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

The simplest category of XML Java applications is the kind of Java application that stores information in XML documents (files). This is illustrated in Figure 1. By using XML to create your own markup languages (i.e. your own file formats for your information) in an open way, you don't have to use propietary and binary file formats. Using XML over proprietary binary file formats, allows your applications to have immense inter operability across platforms, applications and even programming languages. Since any kind of markup language can be defined using XML (you can even formalize it by creating a DTD for it) applications can store their information using their own markup languages. For example, address book information can be stored in an AddressBookML file. A few commercial programs currently available allow saving their application data to XML files, e.g., Framemaker can save its documents as XML files.

In order to create applications of this category, you might have to define a DTD for your information. Then you have to write classes to import and export information from your XML document(s) (validating using your application's DTD if you have one). You must also write the classes which create the user interface in your application. The user of your application can view and modify information using the GUI (graphical user interface), and they can save (and load) their information to (and from) an XML file (that might use your DTD); in other words, they can save (and load) their information to (and from) an ApplicationML file (where Application is the name of your application). Some examples are AddressBookML, MathML, SVGML, etc.

The classes that import and export information from your ApplicationML file must use the parser and SAX or DOM API in order to import the information. These classes can access this information by using one of the following strategies:

    advantage to plan ahead and use all of the tools you can. To take thepreceding example a little further, suppose that a navigational baris added to the page. Within this bar, hyperlinks should be yellow,not dark red. If the bar is marked with an ID ofnavbar, then you need only add this rule:

    #navbar A:link {color: yellow;}

    This will change the color of hyperlinks within the navigation barwithout affecting other hyperlinks throughout the document.