File:  [mozdev] / books / www / chapters / ch04.html
Revision 1.19: download - view: text, annotated - select for diffs - revision graph
Fri Apr 4 16:27:40 2003 UTC (17 years, 2 months ago) by cdn
Branches: MAIN
CVS tags: HEAD

    1:     <link rel="prev" href="" />
    2:     <link rel="next" href="" />
    4:     <style type="text/css">
    5:       div.c13 {font-weight: bold; text-align: center}
    6:       div.c12 {text-align: center}
    7:     </style>
    9:     <h2>Chapter 4</h2>
   10:     <h1><a name="77060"></a> CSS in Mozilla Applications</h1>
   11:     <p>This chapter describes how Cascading Style Sheets (CSS) are
   12:     used to create the look and feel of a Mozilla application's
   13:     interface. Although XUL has a central role in creating a
   14:     structure for an application's interface, defining widgets and
   15:     their functionality, and creating the basic application code,
   16:     it is CSS that creates the visible portion of an application.
   17:     XUL and CSS often work so closely together that they seem
   18:     inseparable, but XUL is generally responsible for the structure
   19:     of an application's interface and CSS is responsible for the
   20:     application's presentation. As described in the next sections,
   21:     it is not until an XPFE application has been "skinned," or
   22:     styled with stylesheets, that it has a usable interface.</p>
   23:     <p>The first few sections in this chapter provide basic
   24:     information about using CSS and some examples of how the
   25:     Mozilla interface is created. They include reference material
   26:     you can refer back to as you learn more. Starting with the
   27:     "Creating New Skins" section, you can dive in, have some fun
   28:     with CSS, and begin to create your own skins. The xFly package
   29:     example created earlier in the book shows how to add custom
   30:     styles to the XUL files you created in Chapters <a href=
   31:     "ch02.html#68959">2</a> and <a href=
   32:     "ch03.html#32764">3</a>.</p>
   33:     <h2><a name="77061"></a> Interface Basics</h2>
   34:     <p>Before describing the 
   35:     <!--INDEX interfaces:(see also user interface)[interfaces:zz(see also user interface)] -->
   36:     <!--INDEX user interface:overview;UI (see user interface) -->
   37:     practice of using 
   38:     <!--INDEX CSS (Cascading Style Sheets):user interfaces --> CSS,
   39:     let's get some basic theory out of the way. When we talk about
   40:     the interface of an application, we mean all of the parts of
   41:     the application that are displayed and allow the user to
   42:     interact. Buttons, windows, pages, menus, sliders, and
   43:     descriptive text are all parts of the interface. In Mozilla,
   44:     XUL usually defines the basic structure of the interface and
   45:     CSS defines its presentation. These two aspects of the
   46:     interface-the way it's organized and the way it's presented-are
   47:     kept as distinct from one another as possible in Mozilla and in
   48:     many good programming environments. Indeed, this separation is
   49:     what gives rise to the concept of <!--INDEX skins --> 
   50:     <!--INDEX user interface:skins --> skins-coherent, separate,
   51:     and typically swappable "looks" for the same underlying
   52:     structure. Mozilla uses Cascading Style Sheets, a quickly
   53:     evolving series of standards already common in HTML web page
   54:     presentation, to define the skin of XUL application
   55:     interfaces.</p>
   56:     <h3><a name="77062"></a> Skins Versus Themes</h3>
   57:     <p>When we <!--INDEX skins:compared to themes --> 
   58:     <!--INDEX themes:compared to skins --> 
   59:     <!--INDEX user interface:skins:compared to themes --> say
   60:     <i>skin</i> in this 
   61:     <!--INDEX CSS (Cascading Style Sheets):skins:themes and -->
   62:     chapter, we refer to the look of the interface-to the CSS
   63:     styles and its relationship to the XUL structure underneath.
   64:     The term <i>theme</i> is also used often in conjunction with
   65:     interfaces and skins. These words are used interchangeably,
   66:     although there are some differences in their meaning.</p>
   67:     <p>A single, overall theme is made up of many skins. The
   68:     Navigator component's skin described in <i>
   69:     <!--INDEX navigator.css --> navigator.css</i>, for example, is
   70:     part of the overall Modern theme of Mozilla. Following this
   71:     definition, the Modern theme may be made up of as many as 20 or
   72:     30 different skins corresponding to the major components and
   73:     major UI features within those components. In addition to
   74:     <i>navigator.css</i>, for example, there are stylesheets for
   75:     <i>toolbar.css</i>, <i>linkToolbar.css</i>, and others, which
   76:     collectively make up the Navigator skin. The CSS files may also
   77:     be described as skins, as when this book instructs you to "open
   78:     the <i>messenger.css</i> skin in a text editor." All skins of a
   79:     particular kind or look organized together comprise a single
   80:     theme.</p>
   81:     <p>Themes are also often used to refer to the different looks
   82:     that you can download and install for Mozilla and Netscape 6.x
   83:     and 7.x. (To get new themes for the Mozilla browser go to View
   84:     &gt; Apply Themes &gt; Get New Themes.) Any application created
   85:     with Mozilla, though, can have different themes that users can
   86:     install and select to customize the look of that
   87:     application.</p>
   88:     <p>This distinction between a skin and a theme is not
   89:     enforced-or even acknowledged-by many people in the Mozilla
   90:     community, so you will see a profligate use of these terms in
   91:     practice. Try to remain calm. The terminology differences
   92:     aren't important. What is important is that you can create one
   93:     (or many) looks for your application using CSS. This chapter
   94:     will show you how.</p>
   95:     <h3><a name="77063"></a> Limitations of a Skin</h3>
   96:     <p>Skins are used <!--INDEX skins:limitations of --> 
   97:     <!--INDEX user interface:skins:limitations of --> to style the
   98:     structure of an interface that has been created with XUL. Once
   99:     the interface has been defined in XUL, that structure is set
  100:     and CSS can be used to change how that structure will look, but
  101:     can't be used to change the structure itself. In practice, this
  102:     means that you can use CSS to change the way a button
  103:     looks--but to move a button from one toolbar to another within
  104:     the interface, you need to edit your XUL code. Skins generally
  105:     affect the usability or appearance, but not the functionality
  106:     of an interface, though the use of XBL in CSS is an exciting
  107:     exception to this rule, as you will see.</p>
  108:     <p>This separation of the style and the content of an
  109:     application means that there are a number of things you can't
  110:     change in an application using CSS. Here are some examples of
  111:     the kinds of interface elements that cannot be manipulated with
  112:     a skin.</p>
  113:     <ul>
  114:       <li>The position and contents of menus and menu items and the
  115:       functionality they trigger.</li>
  116:       <li>The overall layout and functionality of buttons.</li>
  117:       <li>The general layout of the application (although you can
  118:       use CSS to hide sections of an interface).</li>
  119:     </ul>
  120:     <p>While the underlying structure of menus and buttons cannot
  121:     be changed in the process of editing a theme, you can, of
  122:     course, change the appearance of things quite radically. In
  123:     fact, you can change whether an element-say, an item in a
  124:     menu-has any visibility using the <tt>visibility</tt> or
  125:     <tt>display</tt> CSS properties. One of the Mozilla extensions
  126:     to CSS, <tt>-moz-box-ordinal</tt>, lets you set the order in
  127:     which the elements in a container are displayed. We describe
  128:     these extensions and others later in this chapter in the
  129:     section <a href="#77083">"Special Mozilla Extensions</a>."</p>
  130:     <h3><a name="77064"></a> Theme Abstraction (or Building Good
  131:     Skins)</h3>
  132:     <p>One of the most 
  133:     <!--INDEX themes:creating, design considerations --> 
  134:     <!--INDEX skins:creating:design considerations --> important 
  135:     <!--INDEX design issues, user interfaces:themes and skins -->
  136:     parts of a well-written theme is that it be as separate as
  137:     possible from the actual structure of the interface-that it be
  138:     abstracted as a layer so it can be switched or updated without
  139:     affecting or forcing you to edit the underlying XUL. Keeping an
  140:     application's style separate is not mandatory, however, and you
  141:     can have all presentation code in your XUL files, although we
  142:     explain why this isn't a good idea.</p>
  143:     <p>As we have tried to stress, at the most basic level,
  144:     abstraction means that the XUL should describe the structure
  145:     and the CSS should describe the presentation, or look, of the
  146:     interface. In reality, of course, the presentation layer is
  147:     itself divided into different layers, where lower, more basic
  148:     files like <i>xul.css</i> describe the look and feel of common
  149:     UI elements such as buttons and menus, and higher-level CSS
  150:     files consistently describe the layout and stylistic details of
  151:     a component. When working on a theme or skin for your
  152:     application, you should use as few inline style attributes as
  153:     you can, as well as ensure that your themes are organized into
  154:     component subdirectories and that one skin does not depend on
  155:     another that is farther down in the "skin hierarchy." (This is
  156:     discussed later in this chapter in the <a href="#77087">"CSS
  157:     and Skin Hierarchies</a>" section.).</p>
  158:     <blockquote>
  159:       <hr>
  160:       <b>Planning Your Interface</b> 
  161:       <p>Before you begin 
  162:       <!--INDEX user interface:planning considerations --> using
  163:       CSS and images to style your XUL application code, it's
  164:       important to have a sense of where your interface is heading.
  165:       Begin by asking yourself some questions. What should the
  166:       buttons look like? Do you want to give users the ability to
  167:       switch skins in your application, as they can in the Mozilla
  168:       browser? How will your application be affected when the user
  169:       switches skins in Mozilla? What, if any, are the differences
  170:       on the different platforms on which you expect users to run
  171:       your application?</p>
  172:       <p>Although creating interfaces using XUL and CSS is fun and
  173:       fast, it's best to do a mockup of your interface before you
  174:       begin so you know where you are heading (both Adobe Photoshop
  175:       and the GIMP are excellent tools for creating sophisticated
  176:       images and mock-ups). The creators of the Modern and Classic
  177:       themes do lots of visualization of the themes in image
  178:       editing software and go through several iterations of testing
  179:       and feedback.</p>
  180:       <p>One of the great advantages of using such an approach is
  181:       that you will undoubtedly develop images and icons for your
  182:       interface anyway, and you can slice and dice your mockup to
  183:       get, for example, the icons for your buttons, the background
  184:       images, and other real parts of the interface. You may find
  185:       that you can actually use most of the mockup in your actual
  186:       interface! See <a href="#77084">"Referencing Images in
  187:       CSS</a>" later in this chapter for an explanation of how this
  188:       image slicing can work in an advanced way when you have
  189:       XBL-based widgets that use GIF images that are stitched
  190:       together.</p>
  191:       <p>Because the overall theme of an application will most
  192:       likely consist of a large number of individual graphic
  193:       elements and widgets, pay special attention to considerations
  194:       of color palette, web-optimized file formats such as
  195:       <i>.gif</i> and <i>.png</i>, and file size to make sure your
  196:       interface looks good and loads quickly.</p>
  197:       <hr>
  198:     </blockquote>
  199:     <h3><a name="77065"></a> Cross-Platform 
  200:     <!--INDEX STARTRANGE==Cross-Platform:interface considerations -->
  201:     Interface Considerations</h3>
  202:     <p>Often in 
  203:     <!--INDEX STARTRANGE==user interface:design issues, cross-platform considerations -->
  204:     <!--INDEX STARTRANGE==design issues, user interfaces:cross-platform considerations -->
  205:     traditional interface development, you try to make things look
  206:     and work right on a single platform. Using something like MFC
  207:     on Windows, for example, you can drop in the widget it provides
  208:     and be reasonably assured that the interface will look like a
  209:     Windows application interface whenever and wherever your
  210:     application is run.</p>
  211:     <p>When you do cross-platform 
  212:     <!--INDEX Cross-Platform:user interface development --> user
  213:     interface development, you need to be aware of how your
  214:     application will look on the platforms on which it will be
  215:     used. One common difference, for example, is the layout of
  216:     scrollbars in Windows applications and in Macintosh
  217:     applications. On Windows, scrollbars typically have buttons at
  218:     either end that advance the scrollbar button itself. On the
  219:     classic Macintosh, the scrollbars are configured so that the
  220:     buttons are clustered together. The difference is subtle, but
  221:     it is a source of huge contention in the Mozilla world. <a
  222:     href="#77002">Figure 4-1</a> shows the difference between the
  223:     scrollbars on the two platforms. (This figure also shows a
  224:     small notch in the lower righthand corner that is part of all
  225:     classic Macintosh application windows and that shifts part of
  226:     the Mozilla interface over to the left.)</p>
  227:     <div class="c12">
  228:       <img src="foo.gif">
  229:     </div>
  230:     <p><i>Figure 4-1: <a name="77002"></a></i> <i>Scrollbars on
  231:     Windows and on the Macintosh</i></p>
  232:     <p>When you use the <!--INDEX Cross-Platform:XPFE --> 
  233:     <!--INDEX XPFE:user interface cross-platform considerations -->
  234:     XPFE, you use a single code base to deploy on any number of
  235:     different platforms. In the Mozilla code, there are some tricks
  236:     for making things work differently on different platforms. Like
  237:     scrollbars, the layout of buttons in dialogs is another
  238:     important area of platform difference. The layout code for the
  239:     Open Web Location dialog, for example, is defined in
  240:     platform-specific files, and slightly different dialog layouts
  241:     are deployed transparently to users (depending on their
  242:     platform). <a href="#77004">Figure 4-2</a> illustrates the
  243:     differing layouts of this dialog on different platforms (note
  244:     the different positions of the Open and Cancel buttons in the
  245:     two images).</p>
  246:     <div class="c12">
  247:       <img src="foo.gif">
  248:     </div>
  249:     <p><i>Figure 4-2: <a name="77004"></a></i> <i>The Open Web
  250:     Location dialog in Windows and the Macintosh</i></p>
  251:     <p>If you look in the global resources area of the <i>xpfe</i>
  252:     in the source code (using a tool like Mozilla's LXR), you can
  253:     see the platform subdirectories where the buttons in the
  254:     dialogs are arranged with <tt>&lt;spacer /&gt;</tt> 
  255:     <!--INDEX spacer element, XUL:user interface cross-platform considerations -->
  256:     elements and different alignments:</p>
  257: <pre>
  258: mozilla/xpfe/global/resources/content/
  259: mac/
  260: platformDialogOverlay.xul
  261: os2/
  262: platformDialogOverlay.xul
  263: unix
  264: platformDialogOverlay.xul
  265: win
  266: platformDialogOverlay.xul
  267: </pre>
  268:     <p>These platform-specific files allow the application
  269:     developer to write XUL that works the same way on every
  270:     platform, but preserves subtler aspects of an interface that
  271:     users expect from their 
  272:     <!--INDEX ENDRANGE==user interface:design issues, cross-platform considerations -->
  273:     <!--INDEX ENDRANGE==design issues, user interfaces:cross-platform considerations -->
  274:     <!--INDEX ENDRANGE==Cross-Platform:interface considerations -->
  275:     platform.</p>
  276:     <h2><a name="77066"></a> Introduction to CSS in Mozilla</h2>
  277:     <p>Now that you have absorbed some of the most important basic
  278:     aspects of interface design, we can begin to discuss how
  279:     Mozilla uses CSS and images to make actual interfaces out of
  280:     the structure defined in the XUL files. Though XUL contains the
  281:     widgets and structure upon which the interface rests, it is not
  282:     until at least some basic skin information has been loaded into
  283:     the XUL that the interface becomes visible and editable by the
  284:     user. In addition to this, CSS binds XBL widgets to the basic
  285:     structure of the XUL code, allowing extended content to appear
  286:     in your document. For more information about XBL, see <a href=
  287:     "ch07.html#70326">Chapter 7</a>.</p>
  288:     <h3><a name="77067"></a> Basic XUL + CSS Interaction</h3>
  289:     <p>XUL and CSS interact at two basic levels in Mozilla. At the
  290:     file level, XUL picks up CSS information by explicitly loading
  291:     CSS stylesheets at runtime. At the element level, selectors
  292:     bind CSS rules to specific XUL elements or groups of elements.
  293:     For an XUL element to pick up a style defined in a CSS file,
  294:     the XUL file must load the CSS file, and an element or group of
  295:     elements in the XUL must match a selector in the CSS rule. We
  296:     discuss these basic levels of interaction in the following two
  297:     sections.</p>
  298:     <h4><a name="77068"></a> CSS and XUL file interaction</h4>
  299:     <p>Like HTML, 
  300:     <!--INDEX CSS (Cascading Style Sheets):XUL:file interaction -->
  301:     <!--INDEX XUL (XML-based User-interface Language):CSS:file interaction -->
  302:     XUL loads style information by including a specific processing
  303:     instruction somewhere at the top of the file. There are various
  304:     ways to apply style to HTML pages, including the common example
  305:     below, in which a 
  306:     <!--INDEX link element, loading stylesheets --> <tt>&lt;link
  307:     /&gt;</tt> element with a URI loads an external stylesheet that
  308:     holds the style information for the web page.</p>
  309: <pre>
  310: &lt;link rel="stylesheet" href="../style.css" type="text/css"&gt;
  311: </pre>
  312:     <p>In XUL, however, you must use one or more special processing
  313:     instructions at the top of the XUL file to load the 
  314:     <!--INDEX stylesheets:loading --> 
  315:     <!--INDEX CSS (Cascading Style Sheets):(see also stylesheets)[CSS (Cascading Style Sheets):zz(see also style sheets)] -->
  316:     CSS stylesheet information, or skin, into the XUL.</p>
  317: <pre>
  318: &lt;?xml-stylesheet href="chrome://global/skin" type="text/css"?&gt;
  319: </pre>
  320:     <p>Note that the XUL 
  321:     <!--INDEX URLs (Universal Resource Locators):stylesheet loading -->
  322:     stylesheet loading supports the use of <tt>http://</tt> and
  323:     <tt>file://</tt> type URLs, but most often, the 
  324:     <!--INDEX chrome:URLs, stylesheet loading -->
  325:     <tt>chrome://</tt> type URL is used, which points to files that
  326:     are available in the application's chrome subdirectory and that
  327:     are registered with the chrome registry. The example above uses
  328:     a special feature of this chrome type URL, which resolves
  329:     directory pointers to files within those directories that have
  330:     the same name as the directory itself (thus serving as a
  331:     shorthand for main theme stylesheets). The chrome URL
  332:     <tt>chrome://global/skin</tt>, in other words, loads a
  333:     stylesheet found at
  334:     <tt>chrome://modern.jar:/global/skin/global.css</tt>.</p>
  335:     <blockquote>
  336:       <div class="c13">
  337:         NOTE
  338:       </div>
  339:       <p>XUL also supports the <!--INDEX inline styles --> 
  340:       <!--INDEX stylesheets:inline styles --> use of <i>inline
  341:       styles</i>, which is style information that is applied to
  342:       individual elements with a style attribute. However, this
  343:       practice is generally frowned upon, since it overrides the
  344:       skin information and makes it very difficult for new skins to
  345:       be applied correctly.</p>
  346:     </blockquote>
  347:     <p>Actually, the chrome URL in the example does more than this.
  348:     Another important function of the chrome registry is that it
  349:     keeps track of which packages you have installed, which skin
  350:     you have applied to your application, and resolves URLs like
  351:     <tt>chrome://global/skin</tt> into the global skin information
  352:     for the currently selected skin. If you apply the modern skin,
  353:     for example, then this URL loads the global skin file from the
  354:     <i>modern.jar</i>; if you apply the Classic skin, then the
  355:     chrome URL actually resolves to
  356:     <tt>chrome://classic.jar:/global/skin/global.css</tt> instead.
  357:     This flexibility in the chrome registry abstracts the structure
  358:     in the XUL files from the skin information and allows you to
  359:     create and apply different skins.</p>
  360:     <h4><a name="77069"></a> Applying style rules to XUL</h4>
  361:     <p>In CSS, <!--INDEX CSS (Cascading Style Sheets):selectors -->
  362:     <!--INDEX selectors, CSS --> <i>selector</i> 
  363:     <!--INDEX CSS (Cascading Style Sheets):XUL:applying style rules -->
  364:     <!--INDEX XUL (XML-based User-interface Language):CSS:applying style rules -->
  365:     refers to the element or group of elements to which a style
  366:     rule is bound-to the thing that is selected for styling. In
  367:     some cases, the selector is an actual XUL element. The
  368:     following style rule, for example, says that all XUL
  369:     <tt>&lt;menu/&gt;</tt> elements in the XUL file(s) into which
  370:     this CSS is loaded will have a red background color:</p>
  371: <pre>
  372: menu {
  373: background-color: red;
  374: }
  375: </pre>
  376:     <p>In this case, the element selector names an element (menu)
  377:     directly: all elements of that type match and are styled with
  378:     the rule. In the next few sections, we describe the main types
  379:     of selectors and the style rules that can be applied to them.
  380:     With a couple of notable exceptions (see <a href=
  381:     "#77083">"Special Mozilla Extensions</a>" later in this
  382:     chapter), the CSS you use with XUL is the same one you use for
  383:     HTML elements.</p>
  384:     <h4><a name="77070"></a> Inline styles</h4>
  385:     <p>Another way to 
  386:     <!--INDEX CSS (Cascading Style Sheets):XUL:inline styles --> 
  387:     <!--INDEX XUL (XML-based User-interface Language):CSS:inline styles -->
  388:     apply style to XUL elements is to use inline style rules. Use
  389:     inline styles with caution. All XUL elements have a
  390:     <tt>style</tt> attribute that can be used to define styles
  391:     directly for that element. In the following example, the
  392:     <tt>style</tt> attribute is used (in a common but somewhat
  393:     deprecated manner) to hide the XUL element-to apply a style
  394:     that suppresses rendering of the element (though it still takes
  395:     up space in the UI):</p>
  396: <pre>
  397: &lt;menuitem id="e_src"
  398: label="&amp;editsrc.label;"
  399: style="visibility: none;" /&gt;
  400: </pre>
  401:     <p>When you use inline styles, the syntax does not include the
  402:     brackets, but you can still add multiple style rules by using
  403:     the semicolon. The item before the colon is the property, and
  404:     the item after it is its value. The format of inline styles is
  405:     as follows:</p>
  406: <pre>
  407: style="style attribute1: value[; style attribute2: value; etc...]"
  408: </pre>
  409:     <p>The reason why inline styles are frowned upon in XUL and
  410:     skin development is that they can be extremely difficult to
  411:     locate and work around when you design a new skin and want to
  412:     change the appearance of an element that has an inline style.
  413:     The style attribute takes precedence over styles applied from
  414:     other sources-inline styles are the last rule in the cascade of
  415:     style rules-so they cascade over styles defined in a skin and
  416:     may "break" the overall look of that skin.</p>
  417:     <p>Besides this problem, many tricks for which application
  418:     developers use the inline style can be done using XUL
  419:     attributes. It's very common to use the CSS attribute-value
  420:     pairs display: <tt>none;</tt> or visibility: <tt>none;</tt> to
  421:     hide elements in order to change what's available from the
  422:     interface. However, smart XUL developers use the <tt>hidden or
  423:     thecollapse</tt> attribute instead, thereby keeping structural
  424:     matters as separate from style matters as possible.</p>
  425:     <h3><a name="77071"></a> Stylesheet Syntax</h3>
  426:     <p>Cascading Style Sheets 
  427:     <!--INDEX STARTRANGE==style definitions --> 
  428:     <!--INDEX STARTRANGE==CSS (Cascading Style Sheets):style definitions -->
  429:     are the blueprints for Mozilla skins. In Cascading Style
  430:     Sheets, style definitions take the following basic form:</p>
  431: <pre>
  432: element {
  433: style attribute1: value;
  434: style attribute2: value;
  435: style attribute3: value;
  436: }
  437: </pre>
  438:     <p>For example, the following definition makes all XUL menus
  439:     appear with a one-pixel border, a light-blue background, and
  440:     ten-point fonts:</p>
  441: <pre>
  442: menu {
  443: border: 1px;
  444: background-color: lightblue;
  445: font-size: 10pt;
  446: }
  447: </pre>
  448:     <p>This is an example of using the element itself-in this case,
  449:     a "menu"-as a selector (the item to which the style definition
  450:     is applied). In addition to the basic element selector and
  451:     style rules, CSS provides the application of style information
  452:     to classes of elements, element IDs, and elements with
  453:     particular attributes or states. The following three sections
  454:     demonstrate the basic format for these three common style
  455:     selectors.</p>
  456:     <h4><a name="77072"></a> The element selector</h4>
  457:     <p>The <i>element</i> <i>selector</i> is 
  458:     <!--INDEX element selectors, CSS --> 
  459:     <!--INDEX CSS (Cascading Style Sheets):selectors:element --> 
  460:     <!--INDEX selectors, CSS:element --> the most basic kind of
  461:     selector. It is just the name of the element to be styled at
  462:     the front of the style rule. In the previous example, the
  463:     <tt>&lt;menuitem /&gt;</tt> element, defined in a XUL file that
  464:     loads this style rule, will have a light blue background
  465:     color:</p>
  466: <pre>
  467: element { attribute: value; }
  468: menuitem  { background-color: lightblue; }
  469: </pre>
  470:     <h4><a name="77073"></a> The pseudoelement selector</h4>
  471:     <p>The <i>pseudoelement</i> <i>selector</i> 
  472:     <!--INDEX pseudoelement selectors, CSS --> 
  473:     <!--INDEX CSS (Cascading Style Sheets):selectors:pseudoelement -->
  474:     <!--INDEX selectors, CSS:pseudoelement --> selects a piece of
  475:     an element for styling. While a selector like <tt>menuitem</tt>
  476:     picks up all menu items in a given XUL document, a
  477:     pseudoelement selector like <tt>menuitem:first-letter</tt>
  478:     binds the rule's styles to only the first letter in a
  479:     <tt>menuitem</tt> value.</p>
  480: <pre>
  481: menuitem:first-letter { text-decoration: underline; }
  482: description:first-line { margin-left: .25in; }
  483: </pre>
  484:     <p>The first style rule above gives all menu items to which it
  485:     applies the look of being <tt>accesskey</tt> enabled. The
  486:     second creates an indentation in the first line of a XUL
  487:     <tt>description</tt> element's text. Menu access keys let you
  488:     open and choose items from a menu by using the underlined
  489:     letters and modifiers (e.g., "F" and <tt>&lt;alt&gt;</tt> to
  490:     open the File menu).</p>
  491:     <h4><a name="77074"></a> The class selector</h4>
  492:     <p>The <i>class selector</i> <!--INDEX class selectors, CSS -->
  493:     <!--INDEX CSS (Cascading Style Sheets):selectors:class --> 
  494:     <!--INDEX selectors, CSS:class --> applies the style rule to
  495:     all XUL widgets of a given class. In the XUL files that define
  496:     the structure of Netscape 7, the class is specified with the
  497:     <tt>class</tt> attribute (e.g., <tt>&lt;menu
  498:     class="baseline"&gt;</tt>) and in CSS with the dot
  499:     notation:</p>
  500: <pre>
  501: element.class { attribute: value;}
  502: menu.baseline {   border: 0px;   font-size: 9pt; }
  503: </pre>
  504:     <p>In this example, all menus with a XUL baseline class have no
  505:     borders and a nine-point font size. Note that you can use the
  506:     class without the preceding XUL element to skin all XUL
  507:     elements with a given class. In <a href="#77030">Example
  508:     4-1</a>, both the XUL box and the XUL menu pick up the style
  509:     given in the "redbox" class style definition.</p>
  510:     <p><i>Example 4-1: <a name="77030"></a></i> <i>Class selector
  511:     in CSS</i></p>
  512: <pre>
  513:  .redbox {
  514:    border: 2px solid red;
  515:    font-size: 9pt;
  516:  }
  517:  &lt;box class="redbox"&gt;
  518:      &lt;menu class="redbox"&gt;
  519:      &lt;menu class="bluebox"&gt;
  520:  &lt;/box&gt;
  521: </pre>
  522:     <h4><a name="77075"></a> The ID selector</h4>
  523:     <p>The CSS <i>ID selector</i> 
  524:     <!--INDEX CSS (Cascading Style Sheets):selectors:ID --> 
  525:     <!--INDEX selectors, CSS:ID --> applies the style rule to a
  526:     unique XUL element. As with <tt>class</tt>, the <tt>ID</tt> is
  527:     specified in the XUL with an attribute (e.g., <tt>&lt;menu
  528:     id="file_menu"&gt;</tt>) and in the CSS with the pound sign
  529:     preceding the <tt>ID</tt> itself. In this example, the menu
  530:     with an ID of <tt>edit</tt> has a red color:</p>
  531: <pre>
  532: element#id { attribute: value;}
  533: menu#edit { color: red;}
  534: </pre>
  535:     <p>In the example above, both the element type and the element
  536:     ID are given. You can also identify elements anonymously
  537:     (though still uniquely) by using just the selector:</p>
  538: <pre>
  539: #whitey {
  540: background-color: white;
  541: margin: .25in;
  542: }
  543: </pre>
  544:     <p>In the case of IDs, these selectors are identical, since
  545:     IDs need to be unique across the whole XUL file. When you use
  546:     classes, however, the typeless style rule is a good way to
  547:     apply your style information to a range of elements.</p>
  548:     <h4><a name="77076"></a> The attribute selector</h4>
  549:     <p>The <i>attribute selector</i> 
  550:     <!--INDEX attribute selectors, CSS --> 
  551:     <!--INDEX CSS (Cascading Style Sheets):selectors:attrribute -->
  552:     <!--INDEX selectors, CSS:attribute --> allows you to style XUL
  553:     elements with particular attributes or with attributes of a
  554:     particular value. In <a href="#77032">Example 4-2</a>, all
  555:     elements with a disabled attribute set to <tt>true</tt> will
  556:     have a light-grey color.</p>
  557:     <p><i>Example 4-2: <a name="77032"></a></i> <i>Attribute
  558:     selector in CSS</i></p>
  559: <pre>
  560:  element [attribute=value] { attribute: value; }
  561:  element [attribute~=value] { attribute: value; }
  562:  *[disabled="true"]
  563:  {
  564:    color: lightgrey;
  565:  }
  566:  menu[value="File"] {
  567:    font-weight: bold;
  568:  }
  569:  [id~="my"] { color: red; }
  570: </pre>
  571:     <p>Note that <a href="#77032">Example 4-2</a> uses the
  572:     <tt>*</tt> character for selecting all elements. This
  573:     "wildcard" selector can be combined with attribute and other
  574:     selectors to make a powerful filter in your CSS stylesheets-but
  575:     of course, in an example like <a href="#77032">Example 4-2</a>,
  576:     it could be omitted and [disabled=true] would still apply to
  577:     all elements with that attribute set to that value.</p>
  578:     <p><a href="#77032">Example 4-2</a> also uses <tt>~=</tt> to
  579:     match attributes that contain the given fragment. In this case,
  580:     any elements that have an ID with the fragment "my" have text
  581:     colored red, as when you want to see all your customized
  582:     elements for debugging purposes.</p>
  583:     <h4><a name="77077"></a> Pseudoclass selectors</h4>
  584:     <p>Another <!--INDEX pseudoclass selectors, CSS --> 
  585:     <!--INDEX CSS (Cascading Style Sheets):selectors:pseudoclass -->
  586:     <!--INDEX selectors, CSS:pseudoclass --> feature of CSS-2 that
  587:     Mozilla makes extensive use of is the <i>pseudoclass</i>. In
  588:     CSS, pseudoclasses are used to represent different states for
  589:     elements that are manipulated by the user, such as buttons. The
  590:     states-represented by pseudoclasses such as <tt>active</tt>,
  591:     <tt>focus</tt>, and <tt>hover-</tt>change when the user
  592:     interacts with an element. The pseudoclasses actually
  593:     correspond to events on the interface elements.</p>
  594:     <p>The : character is used to add these <tt>pseudoclasses</tt>
  595:     in the CSS notation:</p>
  596: <pre>
  597: #forwardButton:hover
  598: {
  599: list-style-image      : url("chrome://navigator/skin/forward-hover.gif");
  600: }
  601: </pre>
  602:     <p>The pseudoclass is often appended to another style. Since
  603:     specific CSS style rules inherit from more general rules (see
  604:     the section <a href="#77087">"CSS and Skin Hierarchies</a>"
  605:     later in this chapter for more information about this
  606:     inheritance), the example above picks up any styles defined for
  607:     the button with the <tt>id</tt> of <tt>forwardButton</tt> (and
  608:     any class-based information, as well as the basic CSS for a
  609:     button), but substitutes whatever image is used with this
  610:     special GIF that represents a button being moused or hovered
  611:     over.</p>
  612:     <p>In Mozilla's Modern skin, the pseudoclasses work
  613:     collectively to give buttons their appearance and behavior.
  614:     Each of the following button images in <a href="#77006">Figure
  615:     4-3</a> is associated with a different pseudoclass (or
  616:     attribute, as we discuss in the next section). As soon as the
  617:     pseudoclass is changed by user interaction (e.g., the user
  618:     hovers the mouse over the button), the state changes and the
  619:     effect is one of seamless transition.</p>
  620:     <div class="c12">
  621:       <img src="foo.gif">
  622:     </div>
  623:     <p><i>Figure 4-3: <a name="77006"></a></i> <i>The different
  624:     states for buttons in the Modern theme</i></p>
  625:     <h4><a name="77078"></a> Element relation selectors</h4>
  626:     <p>Contextual <!--INDEX relational selectors, CSS --> 
  627:     <!--INDEX CSS (Cascading Style Sheets):selectors:relational -->
  628:     <!--INDEX selectors, CSS:relational --> subgroups-elements
  629:     appearing within other elements, such as italicized text within
  630:     a <tt>&lt;p&gt;</tt> element or a <tt>&lt;body&gt;</tt> in
  631:     HTML-can be grouped in CSS, but this is an extremely
  632:     inefficient way to style XUL. CSS2 also provides ways to group
  633:     elements for styling based on their relationship in the object
  634:     model. <a href="#77022">Table 4-1</a> lists these relational
  635:     selectors.</p>
  636:     <p><i>Table 4-1: <a name="77022"></a></i> <i>Relational
  637:     selectors</i></p>
  638: <table width="100%" border="1">
  639:   <tbody>
  641:     <tr>
  642:       <td><b>  Selector</b></td>
  643:     <td><b>  Syntax</b></td>
  644:     <td><b>  Example</b></td>
  646:     </tr>
  647:     <tr>
  649:       <td>  Descendent</td>
  650:     <td> ancestor descendent {                attribute: value;      }</td>
  651:     <td> toolbar.primary menuitem#F {                border: 1px; }</td>
  653:     </tr>
  654:     <tr>
  655:       <td>  Parent-Child</td>
  657:     <td> parent &gt; child {      attribute: value;}</td>
  658:     <td> menu#file &gt; menuitem {      font-weight: bold; }</td>
  660:     </tr>
  661:     <tr>
  662:       <td>  Precedence</td>
  664:     <td> elBefore + elAfter { attribute: value;}</td>
  665:     <td> menuitem#file + menuitem#edit { background-color: black; }</td>
  667:     </tr>
  669:   </tbody>
  670: </table>
  671:     <p>In the descendent example in <a href="#77022">Table 4-1</a>,
  672:     the "F" <tt>menuitem</tt> has a border only when it appears
  673:     within the <tt>toolbar</tt> whose class is given as "primary."
  674:     In the parent-child example, all menu items in a menu with the
  675:     <tt>id</tt> "file" are made bold. Using +, the precedence
  676:     selector says that the "edit" menu should have a black
  677:     background only when it comes after the "file" menu. You can
  678:     use these element relation selectors to create longer
  679:     descensions (e.g., <tt>toolbar.primary &gt; menu#file &gt;
  680:     menuitem#new</tt>), but remember that the processing gets more
  681:     expensive with each new level, and that the descendent
  682:     operation is particularly processor-intensive.</p>
  683:     <h4><a name="77079"></a> The !important keyword</h4>
  684:     <p>As you might <!--INDEX !important keyword (CSS) --> 
  685:     <!--INDEX keywords, CSS --> 
  686:     <!--INDEX CSS (Cascading Style Sheets):!important keyword -->
  687:     imagine, when you have a technology with such strong notions of
  688:     precedence as Cascading Style Sheets (the ID-based style trumps
  689:     the class-based style, inline style attributes trump those
  690:     loaded from an external stylesheet, etc.), you may need to
  691:     identify and set aside certain styles as the most important,
  692:     regardless of where they are found in the cascade.</p>
  693:     <p>This is the role played by the <tt>!important</tt> keyword.
  694:     Sitting to the right of a style value, it specifies that style
  695:     rule should take precedence over all of its competitors and
  696:     that it should be applied all the time. <a href=
  697:     "#77034">Example 4-3</a> demonstrates how no borders are
  698:     rendered on <i>treecells</i> of the class
  699:     <i>treecell-editor</i> because of the <tt>!important</tt>
  700:     keyword.</p>
  701:     <p><i>Example 4-3: <a name="77034"></a></i> <i>!important
  702:     keyword in CSS</i></p>
  703: <pre>
  704:  .treecell-editor,
  705:  .treecell-editor &gt; box {
  706:    margin: 0px !important;
  707:    padding: 0px !important;
  708:  }
  709:  .treecell-editor {
  710:    border: 0px !important;
  711:  }
  712: </pre>
  713:     <p>You can search for the <tt>!important</tt> keyword in the
  714:     LXR Mozilla source code tool and see its use in the Mozilla
  715:     CSS.</p>
  716:     <h4><a name="77080"></a> The inherits value</h4>
  717:     <p>CSS uses <!--INDEX inherits value (CSS) --> 
  718:     <!--INDEX CSS (Cascading Style Sheets):inherits value -->
  719:     inheritance all over the place. Inheritance is implicit in the
  720:     way style rules are applied, stylesheets are organized in the
  721:     chrome, and skins borrow from one another in Mozilla. However,
  722:     a special CSS value indicates that the selector explicitly
  723:     inherits its value from the parent element.</p>
  724:     <p>When a CSS property has a value of <tt>inherit</tt>, that
  725:     property's real value is pulled from the parent element:</p>
  726: <pre>
  727: .child {
  728: color: darkblue;
  729: height: inherit;
  730: background-color: inherit;
  731: }
  732: </pre>
  733:     <p>This block specifies a dark blue color for the font, but the
  734:     values of the other two properties are inherited from the
  735:     parent. In many cases, this has the same effect as not
  736:     specifying any value at all for the child and letting the style
  737:     rules above the current one in the document inheritance chain
  738:     cascade down. However, not all style rules are inherited.
  739:     Properties such as <tt>!important</tt>, <tt>left</tt>, and
  740:     <tt>height</tt> are not inherited automatically by child
  741:     elements, so you must use the <tt>inherit</tt> keyword to pick
  742:     them up.</p>
  743:     <h4><a name="77081"></a> Box layout properties in CSS</h4>
  744:     <p>People sometimes <!--INDEX properties:CSS:box layout --> 
  745:     <!--INDEX layout, CSS box layout properties --> 
  746:     <!--INDEX box layout properties (CSS) --> 
  747:     <!--INDEX CSS (Cascading Style Sheets):properties, box layout -->
  748:     get confused about the various element spacing properties in
  749:     CSS, such as <tt>border</tt>, <tt>padding</tt>, and
  750:     <tt>margin</tt>. Though they work together a lot and often
  751:     affect or overlap one another, these properties specify
  752:     different things, as <a href="#77024">Table 4-2</a> shows.</p>
  753:     <p><i>Table 4-2: <a name="77024"></a></i> <i>CSS spacing and
  754:     layout properties</i></p>
  755:     <table width="100%" border="1">
  756:       <tr>
  757:         <td><b>Property group</b></td>
  758:         <td><b>Description</b></td>
  759:         <td><b>Display</b></td>
  760:       </tr>
  761:       <tr>
  762:         <td>padding</td>
  763:         <td>Defines the space between the element's border and the
  764:         content in the element.</td>
  765:       </tr>
  766:       <tr>
  767:         <td>td {padding-left: .25in;}</td>
  768:       </tr>
  769:       <tr>
  770:         <td>td {padding-left: .0125in;}</td>
  771:         <td>
  772:         </td>
  773:       </tr>
  774:     </table>
  775:     <div class="c12">
  776:       <img src="foo.gif">
  777:     </div>
  778:     <table width="100%" border="1">
  779:       <tr>
  780:         <td>margin</td>
  781:         <td>Defines the space around elements.</td>
  782:       </tr>
  783:       <tr>
  784:         <td>td {margin-left: .25in;}</td>
  785:         <td>
  786:         </td>
  787:       </tr>
  788:     </table>
  789:     <div class="c12">
  790:       <img src="foo.gif">
  791:     </div>
  792:     <table width="100%" border="1">
  793:       <tr>
  794:         <td>border</td>
  795:         <td>Defines the border itself; it can control the
  796:         thickness, color, style, and other aspects of an element's
  797:         border.</td>
  798:       </tr>
  799:       <tr>
  800:         <td>td {border-style: inset;}</td>
  801:       </tr>
  802:       <tr>
  803:         <td>td {border-color: blue;}</td>
  804:       </tr>
  805:       <tr>
  806:         <td>td {border-left-width: 15px;}</td>
  807:         <td>
  808:         </td>
  809:       </tr>
  810:     </table>
  811:     <div class="c12">
  812:       <img src="foo.gif">
  813:     </div>
  814:     <h4><a name="77082"></a> The position property</h4>
  815:     <p><tt>position</tt> is a <!--INDEX position property (CSS) -->
  816:     <!--INDEX properties:CSS:position --> 
  817:     <!--INDEX CSS (Cascading Style Sheets):position property -->
  818:     special CSS property 
  819:     <!--INDEX alignment, CSS position property --> that specifies
  820:     whether the given selector uses absolute or relative
  821:     positioning. Unless you set the <tt>position</tt> property to
  822:     absolute, you cannot use the related <tt>top</tt> and
  823:     <tt>left</tt> properties to set the position of the current
  824:     selector within its parent, as the example in <a href=
  825:     "#77026">Table 4-3</a> demonstrates. The <tt>top</tt> and
  826:     <tt>left</tt> properties, when activated by the absolute
  827:     position, specify the amount of distance from the top and left
  828:     of the document, respectively. You can also set
  829:     <tt>position</tt> to <tt>fixed</tt> to make it stay in one
  830:     place as other content or UI is scrolled or 
  831:     <!--INDEX ENDRANGE==style definitions --> 
  832:     <!--INDEX ENDRANGE==CSS (Cascading Style Sheets):style definitions -->
  833:     moved.</p>
  834:     <p><i>Table 4-3: <a name="77026"></a></i> <i>The position
  835:     property</i></p>
  836:     <table width="100%" border="1">
  837:       <tr>
  838:         <td><b>Example</b></td>
  839:         <td><b>Display</b></td>
  840:       </tr>
  841:       <tr>
  842:         <td>&lt;style&gt;</td>
  843:       </tr>
  844:       <tr>
  845:         <td>#abdiv {</td>
  846:       </tr>
  847:       <tr>
  848:         <td>position: absolute;</td>
  849:       </tr>
  850:       <tr>
  851:         <td>top: 20px;</td>
  852:       </tr>
  853:       <tr>
  854:         <td>left: 70px;</td>
  855:       </tr>
  856:       <tr>
  857:         <td>background-color: lightblue;</td>
  858:       </tr>
  859:       <tr>
  860:         <td>}</td>
  861:       </tr>
  862:       <tr>
  863:         <td>#regdiv {</td>
  864:       </tr>
  865:       <tr>
  866:         <td>background-color: lightblue;</td>
  867:       </tr>
  868:       <tr>
  869:         <td>}</td>
  870:       </tr>
  871:       <tr>
  872:         <td>&lt;/style&gt;</td>
  873:       </tr>
  874:       <tr>
  875:         <td>&lt;div id="regdiv"&gt;other div&lt;/div&gt;</td>
  876:       </tr>
  877:       <tr>
  878:         <td>&lt;div id="abdiv"&gt;abdiv&lt;/div&gt;</td>
  879:         <td>
  880:         </td>
  881:       </tr>
  882:     </table>
  883:     <div class="c12">
  884:       <img src="foo.gif">
  885:     </div>
  886:     <h3><a name="77083"></a> Special Mozilla Extensions</h3>
  887:     <p>Mozilla skins <!--INDEX selectors, CSS:extensions --> 
  888:     <!--INDEX Mozilla:CSS extensions --> 
  889:     <!--INDEX CSS (Cascading Style Sheets):extensions --> 
  890:     <!--INDEX properties:CSS:Mozilla extensions --> 
  891:     <!--INDEX extensions, CSS selectors and properties --> extend 
  892:     <!--INDEX skins:Mozilla CSS extensions --> upon the CSS
  893:     standards in just a few notable ways. These Mozilla CSS
  894:     extensions take the form of special selectors and properties
  895:     with the special <tt>-moz-</tt> prefix, indicating that they
  896:     are not part of the actual CSS specifications. You can find a
  897:     complete list of these CSS keywords by searching for the file
  898:     <i>nsCSSKeyWordList.h</i> in LXR.</p>
  899:     <p>Generally, these extensions are used to define CSS style and
  900:     color values that are hardcoded into the C++ code and available
  901:     for reuse in particular places in the Mozilla themes. You can
  902:     use a few <i>-moz-</i> extensions, such as properties or
  903:     special values or even, in some cases, style-related attributes
  904:     in the XUL (e.g., span[-moz-smiley="s1"], which grabs span
  905:     elements in the HTML editor whose -<tt>moz-smiley</tt>
  906:     attribute is set to <tt>s1</tt> and styles them accordingly).
  907:     Actually, you can use any value in that CSS keyword list. Trial
  908:     and error or a look in the C++ code will reveal what these
  909:     values are. The values, like <tt>-moz-fieldtext</tt> and
  910:     <tt>-moz-mac-menushadow</tt>, usually refer to actual color
  911:     values. A list of some Mozilla CSS extensions appears in <a
  912:     href="#77028">Table 4-4</a>.</p>
  913:     <p><i>Table 4-4: <a name="77028"></a></i> <i>Mozilla CSS
  914:     extensions</i></p>
  915:     <tt>-moz-binding</tt>is a URL pointing to the section in an XML
  916:     bindings file where the XBL is defined:<tt>2px</tt>, you get a
  917:     slightly rounded border, but if you set it to <tt>8px</tt>, you
  918:     get a very round border.<tt>normal</tt>and
  919:     <tt>ignore</tt>.<tt>none</tt>and <tt>normal</tt>.<tt>s5</tt>to
  920:     pick up the laughing smiley image, to <tt>s6</tt>to pick up the
  921:     embarrassed smiley image, and so on.<a href=
  922:     "">
  924:     -moz-image</tt>region is a set of coordinates that designate an
  925:     area within an "image sheet" that should be used as an icon in
  926:     the user interface. The following CSS style definition
  927:     specifies the top- and leftmost button in the
  928:     <i>btn1.gif</i>image sheet used in <a href="#77006">Figure
  929:     4-3</a>to use as the default icon for the Back navigation
  930:     button:<tt>start</tt>, <tt>center</tt>, <tt>end</tt>,
  931:     <tt>baseline</tt>, and <tt>stretch</tt>.<tt>normal</tt>and
  932:     <tt>reverse</tt>.<tt>horizontal</tt>or
  933:     <tt>vertical</tt>.<tt>start</tt>, <tt>center</tt>, or
  934:     <tt>end</tt>.
  936: <table width="100%" border="1">
  937:   <tbody>
  938:     <tr>
  939:       <td><b>  Property</b></td>
  940:       <td><b>  Description</b></td>
  941:     </tr>
  942:     <tr>
  944:       <td> -moz-appearance</td>
  945:     <td>  Specifies that the element should appear, as much as possible, as
  946: an operating-system native.</td>
  947:     </tr>
  948:     <tr>
  949:       <td> -moz-opacity</td>
  950:     <td>  Controls the opacity of any styleable element with a percentage value.
  951: The following example style rule creates a class of buttons that are only
  952: half visible above their backgrounds:                                   
  954:       <pre>.op-butt {  -moz-opacity: 50%;}</pre>
  956:       </td>
  957:     </tr>
  958:     <tr>
  959:       <td> -moz-binding</td>
  960:     <td>  The property for binding XBL to XUL. The value of        <tt>-moz-binding</tt>
  961: is a URL pointing to the section in an XML bindings file where the XBL is
  962: defined:                                                                 
  964:       <pre>new-widget {<br> -moz-binding:  chrome://xfly/bindings/extras.xml#super-button;<br>}</pre>
  966:       </td>
  967:     </tr>
  968:          <tr>
  969:       <td> -moz-border-radius,<br>
  970:      -moz-border-radius-bottomleft,<br>
  971:    -moz-border-radius-bottomright,<br>
  972:    -moz-border-radius-topleft,<br>
  974:    -moz-border-radius-topright</td>
  975:     <td>  Puts rounded corners on regular borders. The degree of rounding depends
  976: on the number of pixels you assign. For example, if you set this property
  977: to        <tt>2px</tt>, you get a slightly rounded border, but if you set
  978: it to       <tt>8px</tt>, you get a very round border.</td>
  979:     </tr>
  980:     <tr>
  981:       <td> -moz-border-colors,<br>
  983: -moz-border-colors-bottom,<br>
  984: -moz-border-colors-left,<br>
  985: -moz-border-colors-right,<br>
  986: -moz-border-colors-top</td>
  987:     <td>  Sets the border colors on the various sides of an element.</td>
  988:     </tr>
  989:     <tr>
  990:       <td> -moz-user-focus</td>
  992:     <td>  Indicates whether the given element can have focus. Possible values
  993: are <tt>normal</tt> and <tt>ignore</tt>.</td>
  994:     </tr>
  995:     <tr>
  996:       <td> -moz-user-select</td>
  998:     <td>  Indicates whether the given element can be selected. Possible values
  999: are <tt>none</tt> and <tt>normal</tt>.</td>
 1000:     </tr>
 1001:     <tr>
 1002:       <td> -moz-smiley</td>
 1004:     <td>  This is typically given as an attribute to the span element in the
 1005: HTML in a composer window and can be set to a value such as        <tt>s5</tt>
 1006: to pick up the laughing smiley image, to <tt>s6</tt> to pick up the embarrassed
 1007: smiley image, and so on.                                                 
 1008:       <p>See the following source file for the values that can be set for
 1009: this special property: </p>
 1010:       <p><a
 1011:  href=""></a>.
 1012:       </p>
 1013:       </td>
 1015:     </tr>
 1016:     <tr>
 1017:       <td> -moz-image-region</td>
 1018:     <td>  This was added to optimize the way image resources are used in the
 1019: Mozilla skins. The value of the        <tt>-moz-image</tt> region is a set
 1020: of coordinates that designate an area within an "image sheet" that should
 1021: be used as an icon in the user interface. The following CSS style definition
 1022: specifies the top- and leftmost button in the <i>btn1.gif</i> image sheet
 1023: used in <a href="#77006">Figure 4-3</a>to use as the default icon for the
 1024: Back navigation button:                                                  
 1026:       <pre>.toolbarbutton-1 {<br>  list-style-image: url("chrome://navigator/skin/icons/btn1.gif");<br>  min-width: 0px;<br>}<br>#back-button {<br>  -moz-image-region: rect(0 41px 38px 0);<br>}</pre>
 1030:       <p> Of the two default skins, these image sheets are found only in
 1031: the Modern skin. They are gradually making their way into the skins; as of
 1032: this writing, there are three or four image sheets in the Modern skin-each
 1033: corresponding to an area, toolbar, or set of buttons in the browser.</p>
 1034:       </td>
 1035:     </tr>
 1036:     <tr>
 1037:       <td> -moz-box-align</td>
 1038:     <td>  Sets the alignment for a XUL element from CSS. Possible values are
 1039:       <tt>start</tt>, <tt>center</tt>, <tt>end</tt>, <tt>baseline</tt>, and
 1040:       <tt>stretch</tt>.</td>
 1042:     </tr>
 1043:     <tr>
 1044:       <td> -moz-box-direction</td>
 1045:     <td>  Sets the direction of a box's child elements. Possible values are
 1046:   <tt>normal</tt> and <tt>reverse</tt>.</td>
 1048:     </tr>
 1049:     <tr>
 1050:       <td> -moz-box-flex</td>
 1051:     <td>  Sets the flexibility of an element relative to its siblings. The value
 1052: is an integer.</td>
 1053:     </tr>
 1054:     <tr>
 1055:       <td> -moz-box-flexgroup</td>
 1057:     <td>  Specifies that a group of elements have the same flex. The value is
 1058: an integer.</td>
 1059:     </tr>
 1060:     <tr>
 1061:       <td> -moz-box-ordinal</td>
 1062:     <td>  Specifies the order of an element relative to its peers in a container.
 1063: By default, the value of this property is set to 1. When you set a new value,
 1064: you can change the order, as in this example, which promotes the "View Source"
 1065: menu item to the top of the menu by demoting the other two:              
 1067:       <pre>&lt;style&gt;<br>  #q { -moz-box-ordinal: 0; } <br>&lt;/style&gt;<br>&lt;menu&gt; <br>  &lt;menuitem id="e" label="e" /&gt; <br>  &lt;menuitem id="v" label="v" /&gt; <br>  &lt;menuitem id="q" label="q" /&gt; <br>&lt;/menu&gt; <br>&lt;/window&gt; </pre>
 1070:       <p>You can also give elements the same ordinal value in CSS and group<br>
 1071: them, making sure they are  not split by new, overlaid items.</p>
 1072:       </td>
 1073:     </tr>
 1074:     <tr>
 1075:       <td> -moz-box-orient</td>
 1076:     <td>  Sets the orientation of a container element. The value can be either
 1077:       <tt>horizontal</tt> or <tt>vertical</tt>.</td>
 1079:     </tr>
 1080:     <tr>
 1081:       <td> -moz-box-pack</td>
 1082:     <td>  Packs the child elements of a container at the        <tt>start</tt>,
 1083:       <tt>center</tt>, or <tt>end</tt>.</td>
 1085:     </tr>
 1087:   </tbody>
 1088: </table>
 1090:     <h3><a name="77084"></a> Referencing Images in CSS</h3>
 1091:     <p>Another basic <!--INDEX skins:images, referencing --> 
 1092:     <!--INDEX images:skins, referencing --> 
 1093:     <!--INDEX CSS (Cascading Style Sheets):images, referencing --> 
 1094:     <!--INDEX referencing:images, CSS --> function of the CSS in
 1095:     any Mozilla skin is to incorporate images into the user
 1096:     interface. A Mozilla skin can contain literally thousands of
 1097:     images, which are all referenced from particular style
 1098:     statements in the CSS. It's common for a single element to
 1099:     point to different versions of an image to reflect different
 1100:     states-as when a second image is used to give a button a
 1101:     pushed-down look as it is clicked-to create dynamism and
 1102:     provide feedback to the user. <a href="#77036">Example 4-4</a>
 1103:     shows the following two style statements handle the regular and
 1104:     active-or depressed-states, respectively.</p>
 1105:     <p><i>Example 4-4: <a name="77036"></a></i> <i>Image in
 1106:     CSS</i></p>
 1107: <pre>
 1108:  button.regular {
 1109:      list-style-image: url(chrome://global/skin/arrow.gif);
 1110:      background-image: url(chrome://global/skin/regbutton.gif);
 1111:  }
 1112:  button.regular:active
 1113:  {
 1114:      background-image: url(chrome://global/skin/button_pushed.gif);
 1115:  }
 1116: </pre>
 1117:     <p>In <a href="#77036">Example 4-4</a>, the second of the two
 1118:     definitions inherits from the first, so it implicitly includes
 1119:     the <i>arrow.gif</i> as a foreground image. The second style
 1120:     definition says that when the XUL button of class
 1121:     <tt>regular</tt> is active, the image <i>button_pushed.gif</i>
 1122:     is used in place of <i>regbutton.gif</i> for the
 1123:     background.</p>
 1124:     <p><a href="#77036">Example 4-4</a> also illustrates 
 1125:     <!--INDEX properties:CSS:referencing images --> the two common
 1126:     stylesheet properties that reference images:
 1127:     <tt>list-style-image</tt> and <tt>background-image</tt>. The
 1128:     <tt><!--INDEX list-style-image property (CSS) -->
 1129:     list-style-image</tt> property specifies an image to go in the
 1130:     foreground of the selector; the <tt>background-image</tt>
 1131:     property specifies a separate image for the background. The
 1132:     availability of these two properties allows you to fine-tuning
 1133:     the images used to style the UI, as in this example, where the
 1134:     arrow icon is preserved and the wider, underlying button is
 1135:     swapped out.</p>
 1136:     <p>In fact, the navigation buttons in the Modern skin are
 1137:     created by using both properties. In this case, the background
 1138:     is the basic round disk as seen in <a href="#77008">Figure
 1139:     4-4</a>, defined in the <tt>toolbarbutton-1</tt> class in
 1140:     <i>communicator\skin\button.css</i>, and the
 1141:     <tt>list-style-image</tt> is the arrow portion of the button,
 1142:     defined in the button ID and sliced out of a button image sheet
 1143:     with the special <tt>-moz-image-region</tt> property (see <a
 1144:     href="#77083">"Special Mozilla Extensions</a>" later in this
 1145:     chapter for a description of image sheets).</p>
 1146:     <div class="c12">
 1147:       <img src="foo.gif">
 1148:     </div>
 1149:     <p><i>Figure 4-4: <a name="77008"></a></i> <i>Composite styles
 1150:     for the reload button</i></p>
 1151:     <h3><a name="77085"></a> Menu Skinning</h3>
 1152:     <p>As an example <!--INDEX menus:CSS, skinning --> 
 1153:     <!--INDEX skins:menus --> 
 1154:     <!--INDEX CSS (Cascading Style Sheets):menus, skins --> of
 1155:     using CSS in applications, <a href="#77038">Example 4-5</a>
 1156:     combines many common selectors described in this chapter in a
 1157:     set of rules for defining the look and basic behavior of menus.
 1158:     The CSS handles the basic look of the menus, their color and
 1159:     style, the look of the menu items when they are hovered over,
 1160:     and the look when they are selected.</p>
 1161:     <p><i>Example 4-5: <a name="77038"></a></i> <i>Mixing CSS and
 1162:     XUL</i></p>
 1163: <pre>
 1164:  &lt;menu id="sample"&gt;
 1165:    &lt;menupopup&gt;
 1166:      &lt;menuitem class="m" label="File" /&gt;
 1167:      &lt;menuitem class="m" label="Edit" /&gt;
 1168:      &lt;menuitem class="m" id="q" label="Quit" /&gt;
 1169:    &lt;/menupopup&gt;
 1170:  &lt;/menu&gt;
 1171:  .m { background-color: lightgray; font-size: 9pt; }
 1172:  .m:hover  { border: 1px; }
 1173:  .m:active { background-color: gray; color: white; }
 1174:  #q:active { background-color: black }
 1175: </pre>
 1176:     <p>When you hover over any of the items in the menu generated
 1177:     by the code in <a href="#77038">Example 4-5</a>, they display a
 1178:     border. When you select the item, it appears momentarily with a
 1179:     dark gray background and white lettering, like reverse video.
 1180:     The Quit menu item, unlike others, appears with a black
 1181:     background. Note that it also picks up the same white lettering
 1182:     as the other items of the <tt>m</tt> class, since this style
 1183:     information is inherited.</p>
 1184:     <h2><a name="77086"></a> Mozilla Skins</h2>
 1185:     <p>At an earlier <!--INDEX chrome:skins, file locations --> 
 1186:     <!--INDEX skins:file locations --> 
 1187:     <!--INDEX files:skins, locations --> point in Mozilla's
 1188:     history, all interface files-the XUL, the CSS, and the
 1189:     images-were stored in directories named after the main Mozilla
 1190:     packages in the application chrome directory. The best way to
 1191:     look at a skin was just to poke around in those directories,
 1192:     change things in the CSS files you found, and reload to see
 1193:     what had changed in the browser. The CSS files are no longer
 1194:     stored in regular directories.</p>
 1195:     <p>To organize things better and make a smaller footprint for
 1196:     Mozilla, all chrome is stored in special compressed archives in
 1197:     the <i>chrome</i> directory. These archives are Java Archive
 1198:     (JAR) files, whose subdirectory structure reflects the
 1199:     structure of Mozilla's major components, to some extent. There
 1200:     is one JAR archive for every theme. By default, Mozilla is
 1201:     distributed with the Classic and Modern themes, represented in
 1202:     the chrome as <tt>classic.jar</tt> and <tt>modern.jar</tt>. <a
 1203:     href="#77010">Figure 4-5</a> shows some of the contents of the
 1204:     <tt>modern.jar</tt> file in a zip utility.</p>
 1205:     <div class="c12">
 1206:       <img src="foo.gif">
 1207:     </div>
 1208:     <p><i>Figure 4-5: <a name="77010"></a></i> <i>The contents of
 1209:     the modern.jar file</i></p>
 1210:     <h3><a name="77087"></a> CSS and Skin Hierarchies</h3>
 1211:     <p>You have 
 1212:     <!--INDEX CSS (Cascading Style Sheets):skins:hierarchy --> 
 1213:     <!--INDEX skins:hierarchy --> <!--INDEX hierarchy:skins --> 
 1214:     <!--INDEX inheritance:skin hierarchies --> already seen some of
 1215:     the structure inherent to CSS in the previous examples. When an
 1216:     element has both a class-based and an id-based rule, for
 1217:     example (as well as a basic element "look and feel" defined in
 1218:     the global skin), the element style is applied. Then, the more
 1219:     specific class-based rule is applied and overwrites the
 1220:     properties of the general rule if they conflict. Finally, the
 1221:     ID-based rule is applied and overwrites whatever conflicting
 1222:     style values are in the more general selectors. In this way,
 1223:     the most specific style rules inherit from the most basic. This
 1224:     is the "cascade" in Cascading Style Sheets. In addition to this
 1225:     definition, the syntax of CSS allows you to specify selector
 1226:     relationships-such as when you create a parent-child selector
 1227:     and apply a style rule to only the selectors that have some
 1228:     other particular element as a parent in the XUL content model.
 1229:     However, there is also a strong inheritance mechanism in the
 1230:     way that the Mozilla browser uses CSS-in the way skin files are
 1231:     organized in the chrome and applied to the XUL. The strong
 1232:     hierarchical structure present in Mozilla's CSS and the XUL
 1233:     allow the chrome registry to maintain the skin and the various
 1234:     components that get skinned as different modules, but find and
 1235:     apply the right resources whenever they are called for. This
 1236:     structure is described in the <a href="#77089">"Basic Skin
 1237:     Structure</a>" section later in this chapter.</p>
 1238:     <h4><a name="77088"></a> Skin inheritance and skin
 1239:     modularization</h4>
 1240:     <p>For the sake of <!--INDEX skins:inheritance --> 
 1241:     <!--INDEX skins:modularization --> 
 1242:     <!--INDEX modularization, skins --> discussion, this book
 1243:     describes two kinds of inheritance: the more basic form, in
 1244:     which a specific skin like <i>navigator.css</i> inherits all
 1245:     style rules from <i>global.css</i>, and modularization, in
 1246:     which navigator skin rules specific to the toolbar are
 1247:     distributed into widget-specific CSS files (e.g.,
 1248:     <i>toolbar.css</i> is part of the global skin). The global
 1249:     skin-once a large, unmodular set of style rules contained in
 1250:     <i>global.css-</i>is now spread out over several modularized
 1251:     CSS files, as <a href="#77012">Figure 4-6</a> shows.</p>
 1252:     <div class="c12">
 1253:       <img src="foo.gif">
 1254:     </div>
 1255:     <p><i>Figure 4-6: <a name="77012"></a></i> <i>XUL file and skin
 1256:     loading</i></p>
 1257:     <p>This modularization makes it possible for a 
 1258:     <!--INDEX XUL (XML-based User-interface Language):skin modularization -->
 1259:     XUL file to load the <i>global.css</i> file in a single
 1260:     statement and use any of the style rules defined in these
 1261:     skins. We will discuss the global skin in more detail in the
 1262:     section <a href="#77093">"Global skin</a>" later in this
 1263:     chapter. Skin inheritance and skin modularization work together
 1264:     to give skins their structure and make it possible to create
 1265:     new skins or apply CSS only to particular parts of the
 1266:     application.</p>
 1267:     <p><a href="#77012">Figure 4-6</a> shows a very specific skin,
 1268:     <i>new.css</i>, inheriting the style information from
 1269:     <i>communicator.css</i> and then being loaded into the XUL
 1270:     file. In a situation like this, <i>ex.xul</i> can use any style
 1271:     rule defined in the <i>communicator.css</i> file (or in any CSS
 1272:     file that it imports).</p>
 1273:     <h3><a name="77089"></a> Basic Skin Structure</h3>
 1274:     <p>Though they look <!--INDEX themes:structure --> 
 1275:     <!--INDEX skins:structure --> very different, the Modern and
 1276:     Classic themes that are installed with Mozilla have similar
 1277:     structures. This is because the structure of a theme reflects,
 1278:     in many ways, the structure of the components to which it
 1279:     applies. So, for example, both themes have subdirectories (in
 1280:     the JAR files in which they are stored) where the CSS and image
 1281:     resources for each of the main components are stored. Modern,
 1282:     for example, has a <i>communicator</i> component subdirectory,
 1283:     and that subdirectory has subdirectories representing the
 1284:     various parts of the communicator interface: bookmarks, help,
 1285:     search, sidebar, and so on. <a href="#77042">Example 4-7</a>
 1286:     shows the Modern and Classically themed Navigation bars side by
 1287:     side.</p>
 1288:     <div class="c12">
 1289:       <img src="foo.gif">
 1290:     </div>
 1291:     <p><i>Figure 4-7: <a name="77014"></a></i> <i>Classic and
 1292:     Modern Navigation toolbars</i></p>
 1293:     <p>Both themes are complete. They each contain all skin
 1294:     resources for the major components of the application.<a name=
 1295:     "b290"></a><a href="#290">[*]</a> The resources themselves
 1296:     vary, but their structures are almost identical. This ability
 1297:     is what makes the skins dynamically changeable.</p>
 1298:     <p>Skin developers can, for example, create a skin for a single
 1299:     component in Mozilla (e.g., messenger) and let the Modern theme
 1300:     continue to take care of the other components for which they
 1301:     have not created any new CSS information. Which components are
 1302:     skinned by which themes is specified in the
 1303:     <i>installed-chrome.txt</i> file, where a single entry
 1304:     represents the application of the appropriate theme resources
 1305:     to a single component, such as navigator. (See <a href=
 1306:     "ch06.html#15291">Chapter 6</a> for more information about this
 1307:     file and about how themes and other packages are registered and
 1308:     applied in Mozilla.) This situation does not apply to new
 1309:     applications like xFly, however, for which the XUL is typically
 1310:     a single package and the CSS that applies to it is another
 1311:     single package. Unlike the Mozilla browser, your application
 1312:     will probably have a single manifest and <i>content</i>
 1313:     subdirectory and a single manifest and <i>skin</i>
 1314:     subdirectory:</p>
 1315: <pre>
 1316: xfly.jar:
 1317: content/
 1318: contents.rdf
 1319: &lt;xul content here&gt;
 1320: skin/
 1321: contents.rdf
 1322: &lt;css content here&gt;
 1323: </pre>
 1324:     <p>An important difference here is that your skin requires a
 1325:     single manifest whereas the Mozilla themes use as many
 1326:     manifests as they have major components to skin. When the
 1327:     application that needs to be skinned is as large as the Mozilla
 1328:     browser, modularity is almost imperative-particularly if that
 1329:     application supports add-on applications (like xFly itself,
 1330:     which will be accessible from the Mozilla Tasks menu when you
 1331:     are done).</p>
 1332:     <h3><a name="77090"></a> The Modern and Classic Themes</h3>
 1333:     <p>If you haven't 
 1334:     <!--INDEX skins:Modern compared to Classic --> 
 1335:     <!--INDEX Modern theme:compared to Classic --> 
 1336:     <!--INDEX Classic theme compared to Modern --> 
 1337:     <!--INDEX themes:Modern:compared to Classic --> already looked
 1338:     at it, using the skin-switching UI (View Menu &gt; Apply Theme
 1339:     &gt; Modern) in Mozilla will give you an idea about the
 1340:     differences between the two skins that come preinstalled with
 1341:     the browser. The Classic skin is modeled after earlier versions
 1342:     of the Mozilla UI and of the Netscape 4.x Communicator product.
 1343:     It has the familiar light grey box look, with the larger,
 1344:     primary-colored navigation button and a squared-off geometry.
 1345:     The Modern theme is a newer take on the browser interface. It
 1346:     has a smoother overall look, with rounded edges on many of the
 1347:     widgets, subtle color differentiations, gradients, and 3D
 1348:     icons.</p>
 1349:     <p>However, both skins sit on top of the same XUL. With one
 1350:     notable exception-a powerful feature of CSS in Mozilla
 1351:     discussed later in this chapter in the <a href=
 1352:     "#77101">"Binding New Widgets to the Interface Using XBL</a>"
 1353:     section-the applications themselves are identical, and themes
 1354:     themselves provide all the differences in the browser's look
 1355:     and behavior.</p>
 1356:     <h3><a name="77091"></a> Skin Files</h3>
 1357:     <p>Obviously, we cannot describe even a fraction of the CSS
 1358:     files that go into making up a single, overall theme. There
 1359:     are, however, some CSS files that help determine how the
 1360:     Mozilla browser looks. In this section, we will go over some of
 1361:     those files so you can see how they relate to one another,
 1362:     where the browser gets its look, and what strategies you might
 1363:     use to create your own complete skin.</p>
 1364:     <p>The following sections provide a brief, representative
 1365:     sampling of the Modern theme. The global skin, the navigator
 1366:     skin, and the communicator skin are discussed as they pertain
 1367:     to the Modern theme in the Mozilla browser.</p>
 1368:     <h4><a name="77092"></a> Navigator skin</h4>
 1369:     <p>One of the <!--INDEX Modern theme:navigator skin --> 
 1370:     <!--INDEX skins:navigator --> <!--INDEX navigator skin --> 
 1371:     <!--INDEX themes:Modern:navigator skin --> most specific and
 1372:     complex skin files in the Modern theme hierarchy is the
 1373:     <i>navigator.css</i> file, which contains style information for
 1374:     the browser itself. When you look through this skin, you will
 1375:     see rules for such things as the Print button. In <a href=
 1376:     "#77040">Example 4-6</a>, note how several selectors are
 1377:     grouped with a single style rule, and how the parent-child
 1378:     relationship between elements (see the earlier section <a href=
 1379:     "#77078">"Element relation selectors</a>" for an explanation of
 1380:     this selector) is used to style print buttons appearing in
 1381:     different places (i.e., under different element parents) in the
 1382:     UI.</p>
 1383:     <p><i>Example 4-6: <a name="77040"></a></i> <i>CSS for print
 1384:     button in navigator skin</i></p>
 1385: <pre>
 1386:  #print-button
 1387:    {
 1388:      -moz-binding :
 1389:        url("chrome://communicator/skin/menubuttonBindings.xml#menubutton-dual-foo");
 1390:      list-style-image : url("chrome://global/skin/print.gif");
 1391:      margin           : 6px 6px 0px 6px;
 1392:    }
 1393:  #print-button&lt;/td&gt;[disabled="true"],
 1394:  #print-button&lt;/td&gt;[disabled="true"]:hover,
 1395:  #print-button&lt;/td&gt;[disabled="true"]:hover:active,
 1396:  #print-button&lt;/td&gt;[disabled="true"] &gt; .menubutton-dual-stack &gt; .menubutton-dual-button,
 1397:  #print-button&lt;/td&gt;[disabled="true"] &gt; .menubutton-dual-stack &gt;
 1398:      .menubutton-dual-button:hover,
 1399:  #print-button&lt;/td&gt;[disabled="true"] &gt; .menubutton-dual-stack &gt;
 1400:      .menubutton-dual-button:hover:active
 1401:    {
 1402:      list-style-image      : url("chrome://global/skin/print-disabled.gif");
 1403:    }
 1404:  #print-button &gt; .menubutton-dual-stack &gt; .menubutton-dual-button:hover
 1405:    {
 1406:      list-style-image      : url("chrome://global/skin/print-hover.gif");
 1407:    }
 1408:  #print-button &gt; .menubutton-dual-stack &gt; .menubutton-dual-button:hover:active
 1409:    {
 1410:      list-style-image      : url("chrome://global/skin/print-clicked.gif");
 1411:    }
 1412:  #print-button &gt; .menubutton-dual-stack &gt; .menubutton-dual-dropmarker-box
 1413:    {
 1414:      margin-left       : 19px;
 1415:      margin-top        : 22px;
 1416:    }
 1417: </pre>
 1418:     <h4><a name="77093"></a> Global skin</h4>
 1419:     <p>Almost all <!--INDEX Modern theme:global skin --> 
 1420:     <!--INDEX skins:global --> <!--INDEX global skin --> 
 1421:     <!--INDEX themes:Modern:global skin --> of the most specific
 1422:     skin files (e.g., <i>navigator.css</i>) inherit from the global
 1423:     skin, which includes but is not limited to the
 1424:     <i>global.css</i> file located in
 1425:     <i>chrome://modern.jar!/skin/global/skin/</i>.</p>
 1426:     <p>The global skin includes other stylesheets that define
 1427:     localizable settings and general global formatting, which the
 1428:     <i>global.css</i> file loads at runtime. If you look at the top
 1429:     of the <i>global.css</i> file as shown in <a href=
 1430:     "#77042">Example 4-7</a>, you can see the stylesheet import
 1431:     statements that collect these skins into a single global
 1432:     skin:</p>
 1433:     <p><i>Example 4-7: <a name="77042"></a></i> <i>CSS Import
 1434:     statements in global skin</i></p>
 1435: <pre>
 1436:  /* ===== global.css ======================================================
 1437:     == Styles that apply everywhere.
 1438:     ======================================================================= */
 1439:  /* all localizable skin settings shall live here */
 1440:  @import url("chrome://global/locale/intl.css");
 1441:  @import url("chrome://global/skin/formatting.css");
 1442:  @namespace url("<a href=
 1443: ""></a>");
 1444:  /* ::::: XBL bindings ::::: */
 1445:  toolbarbutton&lt;/td&gt;[type="menu-button"] {
 1446:     -moz-binding: url("chrome://global/skin/globalBindings.xml#toolbar-menu-button");
 1447:  }
 1448:  .menulist-compact {
 1449:     -moz-binding:
 1450:        url("chrome://global/content/bindings/menulist.xml#menulist-compact");
 1451:  }
 1452:  ...
 1453: </pre>
 1454:     <p>The <i>global.css</i> serves as a base into which these
 1455:     other skins can be loaded. When you load <i>global.css</i> into
 1456:     your XUL file by means of a <tt>xul-stylesheet</tt> processing
 1457:     instruction, you in effect load these skins.</p>
 1458:     <p>Also included in <a href="#77042">Example 4-7</a> are a
 1459:     couple of binding attachments, which attach content to elements
 1460:     that match certain style rules. On a related note, most global
 1461:     skins on a widget-per-widget basis are now included in the
 1462:     binding themselves, as opposed to being imported in a global
 1463:     skin, which used to be the case. Take this button stylesheet
 1464:     inclusion from the XBL file <tt>button.xml</tt> as a case in
 1465:     point:</p>
 1466: <pre>
 1467: &lt;resources&gt;
 1468: &lt;stylesheet src="chrome://global/skin/button.css"/&gt;
 1469: &lt;/resources&gt;
 1470: </pre>
 1471:     <p>Here the XBL specific <tt>&lt;stylesheet&gt;</tt> element
 1472:     includes the stylesheet, which can be included in a binding and
 1473:     then inherited by other button bindings.</p>
 1474:     <h4><a name="77094"></a> The communicator skin</h4>
 1475:     <p>Like <i>global.css</i>, 
 1476:     <!--INDEX Modern theme:communicator skin --> 
 1477:     <!--INDEX skins:communicator --> 
 1478:     <!--INDEX communicator skin --> 
 1479:     <!--INDEX themes:Modern:communicator skin --> the
 1480:     <i>communicator.css</i> file (<a href="#77044">Example 4-8</a>)
 1481:     is another CSS file that does imports to build up the
 1482:     communicator skin. The CSS style rules in the file itself are
 1483:     minimal, but if you look at the top, you can see that many
 1484:     styles that the communicator component uses come from the CSS
 1485:     files also located in the <i>communicator</i> subdirectory of
 1486:     the current skin.</p>
 1487:     <p><i>Example 4-8: <a name="77044"></a></i> <i>CSS information
 1488:     from communicator.css</i></p>
 1489: <pre>
 1490:  /* ==== communicator.css ====================================================
 1491:     == Styles shared everywhere throughout the Communicator suite.
 1492:     ========================================================================== */
 1493:  @import url("chrome://global/skin/");
 1494:  @import url("chrome://communicator/content/communicator.css");
 1495:  @import url("chrome://communicator/skin/brand.css");
 1496:  @import url("chrome://communicator/skin/button.css");
 1497:  @import url("chrome://communicator/skin/formatting.css");
 1498:  @namespace url("<a href=
 1499: ""></a>");
 1500:  /* ::::: online/offline icons ::::: */
 1501:  #offline-status&lt;/td&gt;[offline="true"] {
 1502:    list-style-image: url("chrome://communicator/skin/icons/offline.gif");
 1503:  }
 1504:  #offline-status {
 1505:    list-style-image: url("chrome://communicator/skin/icons/online.gif");
 1506:  }
 1507:  /* ::::: directional button icons ::::: */
 1508:  .up {
 1509:    min-width: 0px;
 1510:    list-style-image: url("chrome://global/skin/arrow/arrow-up.gif");
 1511:  }
 1512:  .up&lt;/td&gt;[disabled="true"] {
 1513:    list-style-image: url("chrome://global/skin/arrow/arrow-up-dis.gif");
 1514:  }
 1515:  .down {
 1516:    min-width: 0px;
 1517:    list-style-image: url("chrome://global/skin/arrow/arrow-dn.gif");
 1518:  }
 1519:  .down&lt;/td&gt;[disabled="true"] {
 1520:    list-style-image: url("chrome://global/skin/arrow/arrow-dn-dis.gif");
 1521:  }
 1522:  .up {
 1523:    list-style-image:url("chrome://global/skin/scroll-up.gif");
 1524:    min-width: 0px;
 1525:  }
 1526:  .up&lt;/td&gt;[disabled="true"] {
 1527:    list-style-image:url("chrome://global/skin/scroll-up-disabled.gif");
 1528:  }
 1529:  .down {
 1530:    min-width: 0px;
 1531:    list-style-image:url("chrome://global/skin/scroll-down.gif");
 1532:  }
 1533:  .down&lt;/td&gt;[disabled="true"] {
 1534:    list-style-image:url("chrome://global/skin/scroll-down-disabled.gif");
 1535:  }
 1536:  .sidebarTree {
 1537:    border: none;
 1538:    margin: 0px !important;
 1539:  }
 1540:  /* ::::: download manager ::::: */
 1541:  #downloadView &gt; treechildren:-moz-tree-image(Name) {
 1542:    margin-right: 2px;
 1543:  }
 1544: </pre>
 1545:     <h2><a name="77095"></a> Creating New Skins</h2>
 1546:     <p>You have <!--INDEX skins:creating --> already created the
 1547:     highest level of the directory structure you will need to
 1548:     create a skin for the xFly application (See "Creating the Hello
 1549:     xFly Package" in <a href="ch02.html#77048">Chapter 2</a>). So
 1550:     far, you have created three subdirectories corresponding to
 1551:     different parts of the package and you have added XUL to the
 1552:     <i>xfly/content</i> subdirectory. In the <i>xfly/skin</i>
 1553:     subdirectory, you will tell the xFly content where to expect to
 1554:     find its skin resources. As just mentioned, Mozilla
 1555:     applications outside of the browser itself typically restrict
 1556:     their skin to a single subdirectory and their skin manifest to
 1557:     a single RDF/XML file.</p>
 1558:     <p>Since the <i>skin</i> subdirectory in your xFly package is
 1559:     already registered, you can create a new CSS file called
 1560:     <i>xfly.css</i>, save it in the <i>skins</i> subdirectory, and
 1561:     load it from your <i>xfly.xul</i> file by adding the following
 1562:     stylesheet loading instruction at the top:</p>
 1563: <pre>
 1564: &lt;?xml-stylesheet href="chrome://xfly/skin" type="text/css" ?&gt;
 1565: </pre>
 1566:     <p>You will recall that the chrome pointer in the <i>href</i>
 1567:     resolves to a file named <i>xfly.css</i> (named after the
 1568:     directory) in the following <i>registered</i> directory in the
 1569:     chrome:</p>
 1570: <pre>
 1571: chrome/xfly/skin/
 1572: </pre>
 1573:     <p>This CSS file will be the worksheet for all CSS for the xFly
 1574:     application. Any style rules you add here and associated with
 1575:     XUL elements in the xFly XUL code will affect the layout and
 1576:     presentation of that code on restart.</p>
 1577:     <h3><a name="77096"></a> Importing the Global Skin</h3>
 1578:     <p>As you <!--INDEX skins:creating:importing global skin --> 
 1579:     <!--INDEX global skin:importing, creating new skins --> 
 1580:     <!--INDEX importing:global skin, creating new skins --> create
 1581:     a new skin for your application, the first step is to make sure
 1582:     that the application imports the global skin in which the most
 1583:     basic look and feel of the XUL widgets is defined. Even if you
 1584:     create a skin that looks completely different than the skins
 1585:     installed with Mozilla, you should import the global skin to
 1586:     avoid having to recreate so much of the basic presentation and
 1587:     behavior of the XUL widgets.</p>
 1588:     <p>As much as possible, the global skin avoids providing
 1589:     theme-specific styles, and instead provides just enough
 1590:     information to make buttons, for example, look like buttons and
 1591:     menu items look like menu items. Increasingly, basic styles are
 1592:     also being defined in the XBL bindings for widgets. For
 1593:     instance, when you use a <tt>toolbar</tt> widget, you use a
 1594:     binding in which certain intrinsic looks and behaviors are
 1595:     defined in a way that's transparent to you and to the user of
 1596:     the application. The style for these bindings is located in the
 1597:     content subdirectories with the binding XML files. In this way,
 1598:     they "stay with" the widget and not with the selected skin. You
 1599:     can easily extend or overwrite any of the style information you
 1600:     pick up from the global skin, but loading the skin is a good
 1601:     place to start.</p>
 1602:     <p>To do this, verify that you have the following line at the
 1603:     top of the <i>xfly.xul</i> file:</p>
 1604: <pre>
 1605: &lt;?xml-stylesheet href="chrome://global/skin" type="text/css" ?&gt;
 1606: </pre>
 1607:     <p>If you do not have this line, add it now to the
 1608:     <i>xfly.xul</i> file and restart Mozilla. You ought to see a
 1609:     plain, UI-like collection of widgets in the XUL window. In the
 1610:     screenshots in <a href="#77016">Figure 4-8</a>, you can see how
 1611:     loading the global skin affects the XUL file.</p>
 1612:     <div class="c12">
 1613:       <img src="foo.gif">
 1614:     </div>
 1615:     <p><i>Figure 4-8: <a name="77016"></a></i> <i>Stylesheet
 1616:     additions to a XUL file</i></p>
 1617:     <p>The first screenshot in <a href="#77016">Figure 4-8</a>
 1618:     shows a XUL file loaded in Mozilla with no skin information.
 1619:     The second is the same XUL file with the global skin loading
 1620:     instruction at the top. The third is a screenshot of that XUL
 1621:     file with an instruction for loading your own stylesheet, which
 1622:     in turn imports the global skin:</p>
 1623: <pre>
 1624: &lt;?xml-stylesheet href="chrome://xfly/skin/sample.css" type="text/css" ?&gt;
 1625: </pre>
 1626:     <p>The CSS information in the skin file <i>sample.css</i>
 1627:     loaded above looks like this:</p>
 1628: <pre>
 1629: @import url(chrome://global/skin/)
 1630: box#bbox { background-color: lightgrey; }
 1631: button#rd { background-color: red; color: white; }
 1632: </pre>
 1633:     <p>Taking advantage of the modularity of Mozilla skins, you can
 1634:     design a decent interface (if the last screenshot above can
 1635:     count as that) with just a few lines of code.</p>
 1636:     <p>Once you import the global skin and see what it buys you in
 1637:     terms of look and feel, you can begin to create your own skin
 1638:     for the xFly, overriding global styles where appropriate,
 1639:     extending them by "cascading" new, more specific style rules
 1640:     for your widgets, or adding new styles.</p>
 1641:     <p>Before you begin to add styles to the <i>xfly.css</i> file,
 1642:     import it (as a blank skin) into <i>xfly.xul</i> so you can see
 1643:     your progress as you go. Add the following line to the top of
 1644:     the <i>xfly.xul</i> file to import the xFly skin from the
 1645:     proper subdirectory of the xFly package:</p>
 1646: <pre>
 1647: &lt;?xml-stylesheet href="chrome://xfly/skin" type="text/css" ?&gt;
 1648: </pre>
 1649:     <p>You won't see anything extra when you quit and restart the
 1650:     application, but you now have the skin structure in place so
 1651:     you can see your work progress.</p>
 1652:     <h3><a name="77097"></a> Getting Started with Custom
 1653:     Styles</h3>
 1654:     <p>When you <!--INDEX skins:creating:general custom styles --> 
 1655:     <!--INDEX CSS (Cascading Style Sheets):skins:defining general custom styles -->
 1656:     make a new skin, it's a good idea to define the most general
 1657:     styles for your application first. As we described above, more
 1658:     specific CSS rules tend to inherit from more general ones. For
 1659:     the xFly application, the most general aspects of the style are
 1660:     the rules that apply to the xFly windows themselves. You can
 1661:     create styles for all windows using the element name,
 1662:     <i>window</i>, or you can define different classes for windows
 1663:     if your application supports them. In the <i>xfly.xul</i> file,
 1664:     for example, the root <tt>&lt;window&gt;</tt> element has the
 1665:     attribute <tt>class="main"</tt>, so it will pick up style rules
 1666:     given for <i>window.main</i>, as shown in <a href=
 1667:     "#77046">Example 4-9</a>.</p>
 1668:     <p>The xFly application has both a main window and pop-up
 1669:     windows, so you might create style rules like the ones that
 1670:     follow to establish the basic look of the xFly application.</p>
 1671:     <p><i>Example 4-9: <a name="77046"></a></i> <i>CSS rules for
 1672:     xFly window</i></p>
 1673: <pre>
 1674:  window.main {
 1675:     background-color:            #cccccc;
 1676:      display:                    block;
 1677:      overflow:                   hidden;
 1678:      font:                       small arial,helvetica,sans-serif,tahoma;
 1679:      padding:                    0px;
 1680:  }
 1681:  window.popup{
 1682:      background-color:           #cccccc;
 1683:      display:                    block;
 1684:      overflow:                   hidden;
 1685:      font:                       small arial,helvetica,sans-serif,tahoma;
 1686:      padding:                    2px;
 1687:      width:                      auto;
 1688:      height:                     auto;
 1689:  }
 1690: </pre>
 1691:     <p>Now, with the two stylesheets (<i>global.css</i> and the
 1692:     <i>xfly.css</i>) referenced at the top, you already have a
 1693:     window that is starting to look like an application.</p>
 1694:     <h3><a name="77098"></a> Creating Styles for the xFly
 1695:     Buttons</h3>
 1696:     <p>Now that <!--INDEX skins:creating:button styles --> 
 1697:     <!--INDEX buttons:styles, creating for custom skins --> you
 1698:     have created a single custom style for the xFly application,
 1699:     you can see how easy it is to associate cascading style rules
 1700:     with any element in your interface. The next logical step is to
 1701:     style the buttons in the xFly sample application, since they
 1702:     make up such a large portion of the interface itself.</p>
 1703:     <p>When you use the button widget without any extra style
 1704:     information, you already get a lot of the button-like
 1705:     presentation and behavior. The button has different looks, for
 1706:     example, when you hover over it and when you click it, and it
 1707:     has a basic three-dimensional shape as seen in <a href=
 1708:     "#77018">Figure 4-9</a>.</p>
 1709:     <div class="c12">
 1710:       <img src="foo.gif">
 1711:     </div>
 1712:     <p><i>Figure 4-9: <a name="77018"></a></i> <i>XUL button with
 1713:     no style</i></p>
 1714:     <p>A common update to regular XUL buttons is to give them
 1715:     images, like the navigation buttons in the main Mozilla browser
 1716:     window. Adding the class-based style rule in <a href=
 1717:     "#77048">Example 4-10</a> to the xFly stylesheet (and, of
 1718:     course, the GIF image itself to the <i>skin</i> subdirectory)
 1719:     will give all the "fly" buttons background images with flies in
 1720:     them. Example 4-10<a name="77048"></a> <i>Custom styles for
 1721:     buttons</i></p>
 1722: <pre>
 1723: {
 1724:    list-style-image: url("chrome://xfly/skin/btnfly.gif");
 1725:  }
 1726:;/td&gt;[disabled="true"] {
 1727:    list-style-image: url("chrome://xfly/skin/btnfly-dis.gif ");
 1728:  }
 1729: {
 1730:    list-style-image: url("chrome://xfly/skin/btnfly-hov.gif ");
 1731:  }
 1732: </pre>
 1733:     <h3><a name="77099"></a> Describing the Skin in RDF</h3>
 1734:     <p>As described <!--INDEX skins:creating:RDF manifest files -->
 1735:     <!--INDEX RDF (Resource Description Framework):files:creating skins -->
 1736:     <!--INDEX manifests:creating skins --> 
 1737:     <!--INDEX files:mainfest, creating skins --> in <a href=
 1738:     "ch06.html#15291">Chapter 6</a>, a manifest must accompany and
 1739:     describe the skin so it can be found and registered. The
 1740:     manifest is an RDF file called <i>contents.rdf</i> that sits at
 1741:     the highest level of the skin (i.e., at the top of the JAR or
 1742:     immediately under the <i>modern</i> directory when extracted to
 1743:     disk). Since the content, skin, and locale of an application
 1744:     are considered different packages, each must have its own
 1745:     manifest.</p>
 1746:     <p>The listing in <a href="#77050">Example 4-11</a> shows the
 1747:     <i>contents.rdf</i> manifest that accompanies the xFly skin
 1748:     resources in the <i>xfly.jar!/skin/</i> directory. Example
 1749:     4-11<a name="77050"></a> <i>Skin manifest for the xFly
 1750:     sample</i></p>
 1751: <pre>
 1752:  &lt;?xml version="1.0"?&gt;
 1753:  &lt;RDF:RDF xmlns:RDF="<a href=
 1754: ""></a>#
 1755:     xmlns:chrome="<a href=
 1756: ""></a>#"&gt;
 1757:    &lt;RDF:Seq about="urn:mozilla:skin:root"&gt;
 1758:      &lt;RDF:li resource="urn:mozilla:skin:classic/1.0" /&gt;
 1759:    &lt;/RDF:Seq&gt;
 1760:    &lt;RDF:Description about="urn:mozilla:skin:classic/1.0"&gt;
 1761:      &lt;chrome:packages&gt;
 1762:        &lt;RDF:Seq about="urn:mozilla:skin:classic/1.0:packages"&gt;
 1763:          &lt;RDF:li resource="urn:mozilla:skin:classic/1.0:xfly"/&gt;
 1764:        &lt;/RDF:Seq&gt;
 1765:      &lt;/chrome:packages&gt;
 1766:    &lt;/RDF:Description&gt;
 1767:  &lt;/RDF:RDF&gt;
 1768: </pre>
 1769:     <p>As you can see, the basic form of the manifest is something
 1770:     like, "This is the classic skin we have (given as a direct
 1771:     child of the RDF root element), which applies to the following
 1772:     packages: <i>xfly</i>." The second group of RDF in this
 1773:     manifest provides a list of packages to which the skin should
 1774:     apply. In the case of the xFly application, all XUL code is a
 1775:     single package. In Mozilla, a <i>contents.rdf</i> file in a
 1776:     package subdirectory of the <i>modern.jar</i>, for example,
 1777:     would describe the communicator package in a similar way, but
 1778:     it would be a composite of other package manifests in the theme
 1779:     to create a single, overarching manifest for the whole theme.
 1780:     <a href="#77052">Example 4-12</a> shows the manifest for just
 1781:     the Mozilla communicator package. Example 4-12<a name=
 1782:     "77052"></a> <i>Manifest for the communicator package of the
 1783:     modern skin in Mozilla</i></p>
 1784: <pre>
 1785:  &lt;?xml version="1.0"?&gt;
 1786:  &lt;RDF:RDF xmlns:RDF="<a href=
 1787: ""></a>#"
 1788:           xmlns:chrome="<a href=
 1789: ""></a>#"&gt;
 1790:    &lt;!-- List all the skins being supplied by this theme --&gt;
 1791:    &lt;RDF:Seq about="urn:mozilla:skin:root"&gt;
 1792:      &lt;RDF:li resource="urn:mozilla:skin:modern/1.0" /&gt;
 1793:    &lt;/RDF:Seq&gt;
 1794:    &lt;!-- Modern Information --&gt;
 1795:    &lt;RDF:Description about="urn:mozilla:skin:modern/1.0"&gt;
 1796:      &lt;chrome:packages&gt;
 1797:        &lt;RDF:Seq about="urn:mozilla:skin:modern/1.0:packages"&gt;
 1798:          &lt;RDF:li resource="urn:mozilla:skin:modern/1.0:communicator"/&gt;
 1799:        &lt;/RDF:Seq&gt;
 1800:      &lt;/chrome:packages&gt;
 1801:    &lt;/RDF:Description&gt;
 1802:  &lt;/RDF:RDF&gt;
 1803: </pre>
 1804:     <p>This RDF/XML file describes a skin to the chrome registry so
 1805:     it can be registered properly. All new packages must be
 1806:     accompanied by these sorts of RDF-based descriptions if they
 1807:     will be made available to users.</p>
 1808:     <h2><a name="77100"></a> What Is Possible in a Skin?</h2>
 1809:     <p>In this final section, we describe a few things that make
 1810:     CSS in Mozilla particularly powerful and cases when this power
 1811:     is curtailed because of the security restrictions.</p>
 1812:     <h3><a name="77101"></a> Binding New Widgets to the Interface
 1813:     Using XBL</h3>
 1814:     <p>A 
 1815:     <!--INDEX CSS (Cascading Style Sheets):widgets, binding with XBL -->
 1816:     <!--INDEX widgets:binding with XBL --> 
 1817:     <!--INDEX skins:widgets, 
 1818:     binding with XBL --> <!--INDEX bindings:XBL:widgets --> 
 1819:     <!--INDEX XBL (eXtensible Binding Language):widgets -->
 1820:     description of skins wouldn't be complete without a mention of
 1821:     binding widgets by using XBL, a very powerful feature of CSS in
 1822:     Mozilla. The <tt>-moz-binding</tt> keyword described in <a
 1823:     href="#77028">Table 4-4</a> is the key to binding special,
 1824:     prefabricated widgets to your XUL. The language in which these
 1825:     widgets are defined is another XML-based language called the
 1826:     Extensible Bindings Language. <a href="ch07.html#77027">Chapter
 1827:     7</a> describes this language in more detail.</p>
 1828:     <p>To see how XBL works, go back and look at the first style
 1829:     rule for "print-button" in <a href="#77040">Example 4-6</a>.
 1830:     The first style statement in that block has a property called
 1831:     <tt>-moz-</tt> <tt>binding</tt>. This property defines a
 1832:     <i>binding</i> for the XUL element styled by this style rule.
 1833:     The <i>chrome URL</i> that the <tt>-moz-binding</tt> property
 1834:     points to is where an XBL-based definition of a print button is
 1835:     located.</p>
 1836:     <p>Creating a style rule in which your XUL element (in this
 1837:     case, a button in which the ID is "print-button") and the use
 1838:     of the <tt>-moz-binding</tt> to point to the XBL defines new
 1839:     properties, behavior, or content for that XUL element, you can
 1840:     add to or totally recreate any widget in your interface. The
 1841:     binding itself is described in XBL, but XBL also provides
 1842:     structures (such as the <tt>&lt;content&gt;</tt> and
 1843:     <tt>&lt;handlers&gt;</tt> child elements) in which you can
 1844:     define new XUL content, new JavaScript, and new XPConnected
 1845:     interfaces. CSS glues the XUL together with the XBL.</p>
 1846:     <p>In the first part of the snippet in <a href="#77054">Example
 1847:     4-13</a>, for example, the CSS rule binds the toolbar button to
 1848:     an XBL binding called <i>menu-button</i>, which adds a button
 1849:     and an image. Example 4-13<a name="77054"></a> <i>CSS and XBL
 1850:     example</i></p>
 1851: <pre>
 1852:  // In the CSS:
 1853:  toolbarbutton&lt;/td&gt;[type="menu-button"] {
 1854:     -moz-binding: url("chrome://global/content/bindings/toolbarbutton.xml#menu-button");
 1855:  }
 1856:  // In the XBL file toolbarbutton.xml:
 1857:  &lt;binding id="menu-button" display="xul:menu"
 1858:      extends="chrome://global/content/bindings/button.xml#menu-button-base"&gt;
 1859:    &lt;resources&gt;
 1860:      &lt;stylesheet src="chrome://global/skin/toolbarbutton.css"/&gt;
 1861:    &lt;/resources&gt;
 1862:    &lt;content&gt;
 1863:      &lt;children includes="observes|template|menupopup|tooltip"/&gt;
 1864:      &lt;xul:toolbarbutton class="box-inherit toolbarbutton-menubutton-button"
 1865:                         anonid="button" flex="1" allowevents="true"
 1866:                         xbl:inherits="disabled,crop,image,label,accessKey,command,
 1867:                                       align,dir,pack,orient"/&gt;
 1868:      &lt;xul:dropmarker type="menu-button" class="toolbarbutton-menubutton-dropmarker"
 1869:                          xbl:inherits="align,dir,pack,orient,disabled"/&gt;
 1870:    &lt;/content&gt;
 1871:  &lt;/binding&gt;
 1872: </pre>
 1873:     <p>When you use the Modern skin, you can see in <a href=
 1874:     "#77020">Figure 4-10</a> that the menu button is a composite of
 1875:     the toolbar button, a dropmarker image resource, and a
 1876:     <tt>menupopup</tt> making the drop-down history available.</p>
 1877:     <div class="c12">
 1878:       <img src="foo.gif">
 1879:     </div>
 1880:     Figure 4-10<a name="77020"></a> <i>Modern menu button</i> 
 1881:     <p>You might also notice in <a href="#77054">Example 4-13</a>
 1882:     that this binding pulls in an external stylesheet
 1883:     (<tt>toolbarbutton.css</tt>), which is contained in the
 1884:     <tt>&lt;resources&gt;</tt> section of the binding. This
 1885:     stylesheet provides all the styles and theme information for a
 1886:     toolbar button, including the type of <tt>menu-button</tt>.
 1887:     More information on stylesheets in XBL can be found in <a href=
 1888:     "ch07.html#70326">Chapter 7</a>.</p>
 1889:     <h3><a name="77102"></a> User Stylesheets</h3>
 1890:     <p>In <!--INDEX user stylesheets --> 
 1891:     <!--INDEX stylesheets:user --> 
 1892:     <!--INDEX CSS (Cascading Style Sheets):user stylesheets --> 
 1893:     <!--INDEX userChrome.css --> <!--INDEX userContent.css -->
 1894:     addition to the many CSS stylesheets that give the user
 1895:     interface its look, Mozilla also lets you create personal
 1896:     stylesheets that apply to all of the chrome and content you
 1897:     view in the browser. Two CSS files, <i>userChrome.css</i> and
 1898:     <i>userContent.css</i>, located in the <i>chrome</i>
 1899:     subdirectory of your user profile, can define rules that apply
 1900:     to all of the Mozilla application interfaces and all web pages
 1901:     you view, respectively. When these two files are
 1902:     present-sometimes they are installed in the user profile and
 1903:     sometimes you create them yourself-they come with example rules
 1904:     that are commented out. However, you can uncomment them and add
 1905:     your own rules to personalize the look of the browser and its
 1906:     content.</p>
 1907:     <p><a href="#77056">Example 4-14</a> shows the default
 1908:     commented rules in <i>userChrome.css</i>. Note the use of the
 1909:     <tt>!important</tt> keyword to specify that these rules should
 1910:     take precedence over rules that come from stylesheets in the
 1911:     current theme. Example 4-14<a name="77056"></a>
 1912:     <i>userChrome.css style rules</i></p>
 1913: <pre>
 1914:  /*
 1915:   * This file can be used to customize the look of Mozilla's user interface
 1916:   * You should consider using !important on rules which you want to
 1917:   * override default settings.
 1918:   */
 1919:  /*
 1920:   * example: make the UI look a little more like Irix (nice readable
 1921:   *          slanted-helvetical menus, funny pink color on text fields)
 1922:   *
 1923:   * input {
 1924:   *   color: black !important;
 1925:   *   background-color: rgb(255, 225, 175) !important;
 1926:   * }
 1927:   *
 1928:   * menubar {
 1929:   *   font-family: helvetica !important;
 1930:   *   font-style: italic !important;
 1931:   *   font-weight: bold !important;
 1932:   *   font-size: 4mm !important;
 1933:   * }
 1934:   */
 1935:  /*
 1936:   * For more examples see <a href=
 1937: ""></a>
 1938:   */
 1939: </pre>
 1940:     <p>If you want to make the content in all your <tt>menu</tt>
 1941:     widgets white so you can read them better, get rid of these
 1942:     defaults and do something like this:</p>
 1943: <pre>
 1944: menu {
 1945: background-color: white !important;
 1946: color: darkblue !important;
 1947: padding: 5px !important;
 1948: }
 1949: </pre>
 1950:     <p>You can also use these stylesheets to change or do away with
 1951:     aspects of the user interface you don't like. The following
 1952:     rule, for example, shrinks the navigation buttons in the Modern
 1953:     theme:</p>
 1954: <pre>
 1955: .toolbarbutton-menubutton-button &gt; .toolbarbutton-box,
 1956: .toolbarbutton-1 &gt; .toolbarbutton-box
 1957: {
 1958: max-width: 40px !important;
 1959: text-align: center !important;
 1960: }
 1961: </pre>
 1962:     <p>Or, if you can think of the appropriate selectors, you can
 1963:     use <i>userContent.css</i> to change the way banner images are
 1964:     displayed (or not displayed), how basic text is presented, or
 1965:     where certain elements of a web page are positioned.</p>
 1966:     <h3><a name="77103"></a> Theme Security Restrictions</h3>
 1967:     <p>To prevent <!--INDEX themes:security considerations --> 
 1968:     <!--INDEX security:themes --> the wholesale overriding of the
 1969:     basic XUL application, various restrictions are placed on
 1970:     themes. In other words, you can do some things in XUL that you
 1971:     cannot do in CSS. The two preinstalled themes in Mozilla,
 1972:     Modern, and Classic use technologies like XBL, JavaScript, and
 1973:     XPConnect to provide additional behavior to the application.
 1974:     They are considered full-blown packages, like entirely separate
 1975:     interfaces (see <a href="ch06.html#15291">Chapter 6</a> for a
 1976:     description the various types of packages and installations).
 1977:     When you install new themes, however, those themes do not have
 1978:     "script access" and have limited access to XBL bindings.</p>
 1979:     <p>Code in the <tt>&lt;implementation&gt;</tt> and
 1980:     <tt>&lt;handler&gt;</tt> structures of an XBL binding are
 1981:     ignored, as are event handlers written in the
 1982:     <tt>&lt;content&gt;</tt> structures.</p>
 1983:     <p>You can write these XBL goodies into your theme if you want
 1984:     (or develop a theme out of the Modern theme, where there is
 1985:     plenty of XBL, and see them disabled in your theme when they
 1986:     were working in that preinstalled version), but Mozilla will
 1987:     not read or execute them. You can use XBL to define new XUL
 1988:     content for a widget by way of CSS, but unless you create an
 1989:     "evil skin," that content has to be simple XUL to show up in
 1990:     your theme at all.</p>
 1991:     <blockquote>
 1992:       <hr>
 1993:       <a name="62192"></a> Evil Skins 
 1994:       <p>In the <!--INDEX evil skins --> 
 1995:       <!--INDEX skins:evil skins --> Mozilla community, the term
 1996:       "evil skins" is sometimes used to describe skins with
 1997:       unlimited script access. An evil skin is a skin for which the
 1998:       security restrictions above do not apply. They can access the
 1999:       DOM of the web page and XUL content, use XPConnect to connect
 2000:       to the Mozilla services in XPCOM, or implement new
 2001:       application code in XBL widgets.</p>
 2002:       <p>Remember that when you develop skins for Mozilla and
 2003:       package them for installation as skins, the script part of
 2004:       your skins will be disabled. However, if you create a skin
 2005:       and then install it as a new package, your skin will not be
 2006:       as limited, and you will have full access to XBL, XPConnect,
 2007:       and the script. To see how to install an evil skin and other
 2008:       new packages in Mozilla, see <a href=
 2009:       "ch06.html#15291">Chapter 6</a>.</p>
 2010:       <hr>
 2011:     </blockquote>
 2012:     <hr>
 2013:     <hr>
 2014:     <a name="290"></a><a href="#b290">[Back]</a> <a name=
 2015:     "77059"></a> There are just a couple of exceptions to this
 2016:     rule. The <i>content</i> directory of a package (typically the
 2017:     place where just the XUL and JS are stored) sometimes holds a
 2018:     file called <i>xul.css</i> . This file defines style
 2019:     information that is so fundamental to the way widgets are
 2020:     rendered more fundamental, even, then <i>global.css</i> and its
 2021:     siblings that it is set apart from the regular skin and put in
 2022:     with the content, where it is loaded automatically. It's not a
 2023:     good idea to edit this file. 
 2024:     <hr>
 2025:     <br>
 2026:     <br>
 2027:     File a <a href=
 2028:     "">Bug</a>
 2029:     for chapter 4. 
 2030:     <?php $hide_text_control=1; $post_to_list=NO; $author=''; // require(NOTES); ?>

FreeBSD-CVSweb <>