Creating Applications with Mozilla-Chapter 4. CSS in Mozilla Applications-P3

Chapter 4. CSS in Mozilla Applications-P3

Figure 4-4. Composite styles for the reload button

4.2.5. Menu Skinning
As an example of using CSS in applications, Example 4-5
combines many
common selectors described in this chapter in a set of rules for defining the
look and basic behavior of menus. The CSS handles the basic look of the
menus, their color and style, the look of the menu items when they are
hovered over, and the look when they are selected.
Example 4-5. Mixing CSS and XUL
<menu id="sample">
<menupopup>
<menuitem class="m" label="File" />
<menuitem class="m" label="Edit" />
<menuitem class="m" id="q" label="Quit" />
</menupopup>
</menu>
.m { background-color: lightgray; font-size: 9pt; }
.m:hover { border: 1px; }
.m:active { background-color: gray; color: white; }
#q:active { background-color: black }
When you hover over any of the items in the menu generated by the code in
Example 4-5
, they display a border. When you select the item, it appears
momentarily with a dark gray background and white lettering, like reverse
video. The Quit menu item, unlike others, appears with a black background.
Note that it also picks up the same white lettering as the other items of the m
class, since this style information is inherited.
4.3. Mozilla Skins

At an earlier point in Mozilla's history, all interface files -- the XUL, the
CSS, and the images -- were stored in directories named after the main
Mozilla packages in the application chrome directory. The best way to look
at a skin was just to poke around in those directories, change things in the
CSS files you found, and reload to see what had changed in the browser. The
CSS files are no longer stored in regular directories.
To organize things better and make a smaller footprint for Mozilla, all
chrome is stored in special compressed archives in the chrome directory.
These archives are Java Archive (JAR) files, whose subdirectory structure
reflects the structure of Mozilla's major components, to some extent. There
is one JAR archive for every theme. By default, Mozilla is distributed with
the Classic and Modern themes, represented in the chrome as
classic.jar and modern.jar. Figure 4-5
shows some of the contents
of the modern.jar file in a zip utility.
Figure 4-5. The contents of the modern.jar file

4.3.1. CSS and Skin Hierarchies
You have already seen some of the structure inherent to CSS in the previous
examples. When an element has both a class-based and an id-based rule, for
example (as well as a basic element "look and feel" defined in the global
skin), the element style is applied. Then, the more specific class-based rule is
applied and overwrites the properties of the general rule if they conflict.
Finally, the ID-based rule is applied and overwrites whatever conflicting
style values are in the more general selectors. In this way, the most specific
style rules inherit from the most basic. This is the "cascade" in Cascading
Style Sheets. In addition to this definition, the syntax of CSS allows you to
specify selector relationships -- such as when you create a parent-child
selector and apply a style rule to only the selectors that have some other
particular element as a parent in the XUL content model. However, there is

also a strong inheritance mechanism in the way that the Mozilla browser
uses CSS -- in the way skin files are organized in the chrome and applied to
the XUL. The strong hierarchical structure present in Mozilla's CSS and the
XUL allow the chrome registry to maintain the skin and the various
components that get skinned as different modules, but find and apply the
right resources whenever they are called for. This structure is described in
the Section 4.3.2
section later in this chapter.
4.3.1.1. Skin inheritance and skin modularization
For the sake of discussion, this book describes two kinds of inheritance: the
more basic form, in which a specific skin like navigator.css inherits all
style rules from global.css, and modularization, in which navigator skin
rules specific to the toolbar are distributed into widget-specific CSS files
(e.g., toolbar.css is part of the global skin). The global skin -- once a
large, unmodular set of style rules contained in global.css -- is now
spread out over several modularized CSS files, as Figure 4-6
shows.
Figure 4-6. XUL file and skin loading

This modularization makes it possible for a XUL file to load the
global.css file in a single statement and use any of the style rules
defined in these skins. We will discuss the global skin in more detail in the
section Section 4.3.4.2
later in this chapter. Skin inheritance and skin
modularization work together to give skins their structure and make it
possible to create new skins or apply CSS only to particular parts of the
application.
Figure 4-6
shows a very specific skin, new.css, inheriting the style
information from communicator.css and then being loaded into the

XUL file. In a situation like this, ex.xul can use any style rule defined in
the communicator.css file (or in any CSS file that it imports).
4.3.2. Basic Skin Structure
Though they look very different, the Modern and Classic themes that are
installed with Mozilla have similar structures. This is because the structure
of a theme reflects, in many ways, the structure of the components to which
it applies. So, for example, both themes have subdirectories (in the JAR files
in which they are stored) where the CSS and image resources for each of the