Chapter 4. CSS in Mozilla Applications-P5 4.4.3. Creating Styles for the xFly Buttons Now that you have created a single custom style for the xFly application, you can see how easy it is to associate cascading style rules with any element in your interface. The next logical step is to style the buttons in the xFly sample application, since they make up such a large portion of the interface itself. When you use the button widget without any extra style information, you already get a lot of the button-like presentation and behavior. The button has different looks, for example, when you hover over it and when you click it, and it has a basic three-dimensional shape as seen in Figure 4-9 . Figure 4-9. XUL button with no style A common update to regular XUL buttons is to give them images, like the navigation buttons in the main Mozilla browser window. Adding the class- based style rule in Example 4-10 to the xFly stylesheet (and, of course, the GIF image itself to the skin subdirectory) will give all the "fly" buttons background images with flies in them. Example 4-10. Custom styles for buttons button.fly { list-style-image: url("chrome://xfly/skin/btnfly.gif"); } button.fly[disabled="true"] { list-style-image: url("chrome://xfly/skin/btnfly- dis.gif "); } button.fly#hover { list-style-image: url("chrome://xfly/skin/btnfly- hov.gif "); } 4.4.4. Describing the Skin in RDF As described in Chapter 6 , a manifest must accompany and describe the skin so it can be found and registered. The manifest is an RDF file called contents.rdf that sits at the highest level of the skin (i.e., at the top of the JAR or immediately under the modern directory when extracted to disk). Since the content, skin, and locale of an application are considered different packages, each must have its own manifest. The listing in Example 4-11 shows the contents.rdf manifest that accompanies the xFly skin resources in the xfly.jar!/skin/ directory. Example 4-11. Skin manifest for the xFly sample <?xml version="1.0"?> <RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22- rdf-syntax-ns# xmlns:chrome="http://www.mozilla.org/rdf/chrome#"> <RDF:Seq about="urn:mozilla:skin:root"> <RDF:li resource="urn:mozilla:skin:classic/1.0" /> </RDF:Seq> <RDF:Description about="urn:mozilla:skin:classic/1.0"> <chrome:packages> <RDF:Seq about="urn:mozilla:skin:classic/1.0:packages"> <RDF:li resource="urn:mozilla:skin:classic/1.0:xfly"/> </RDF:Seq> </chrome:packages> </RDF:Description> </RDF:RDF> As you can see, the basic form of the manifest is something like, "This is the classic skin we have (given as a direct child of the RDF root element), which applies to the following packages: xfly." The second group of RDF in this manifest provides a list of packages to which the skin should apply. In the case of the xFly application, all XUL code is a single package. In Mozilla, a contents.rdf file in a package subdirectory of the modern.jar, for example, would describe the communicator package in a similar way, but it would be a composite of other package manifests in the theme to create a single, overarching manifest for the whole theme. Example 4-12 shows the manifest for just the Mozilla communicator package. Example 4-12. Manifest for the communicator package of the modern skin in Mozilla <?xml version="1.0"?> <RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22- rdf-syntax-ns#" xmlns:chrome="http://www.mozilla.org/rdf/chrome#"> <!-- List all the skins being supplied by this theme --> <RDF:Seq about="urn:mozilla:skin:root"> <RDF:li resource="urn:mozilla:skin:modern/1.0" /> </RDF:Seq> <!-- Modern Information --> <RDF:Description about="urn:mozilla:skin:modern/1.0"> <chrome:packages> <RDF:Seq about="urn:mozilla:skin:modern/1.0:packages"> <RDF:li resource="urn:mozilla:skin:modern/1.0:communicator" /> </RDF:Seq> </chrome:packages> </RDF:Description> </RDF:RDF> This RDF/XML file describes a skin to the chrome registry so it can be registered properly. All new packages must be accompanied by these sorts of RDF-based descriptions if they will be made available to users. 4.5. What Is Possible in a Skin? In this final section, we describe a few things that make CSS in Mozilla particularly powerful and cases when this power is curtailed because of the security restrictions. 4.5.1. Binding New Widgets to the Interface Using XBL A description of skins wouldn't be complete without a mention of binding widgets by using XBL, a very powerful feature of CSS in Mozilla. The - moz-binding keyword described in Table 4-4 is the key to binding special, prefabricated widgets to your XUL. The language in which these widgets are defined is another XML-based language called the Extensible Bindings Language. Chapter 7 describes this language in more detail. To see how XBL works, go back and look at the first style rule for "print- button" in Example 4-6 . The first style statement in that block has a property called -moz- binding. This property defines a binding for the XUL element styled by this style rule. The chrome URL that the -moz- binding property points to is where an XBL-based definition of a print button is located. Creating a style rule in which your XUL element (in this case, a button in which the ID is "print-button") and the use of the -moz-binding to point to the XBL defines new properties, behavior, or content for that XUL element, you can add to or totally recreate any widget in your interface. The binding itself is described in XBL, but XBL also provides structures (such as the <content> and <handlers> child elements) in which you can define new XUL content, new JavaScript, and new XPConnected interfaces. CSS glues the XUL together with the XBL. In the first part of the snippet in Example 4-13 , for example, the CSS rule binds the toolbar button to an XBL binding called menu-button, which adds a button and an image. Example 4-13. CSS and XBL example // In the CSS: toolbarbutton[type="menu-button"] { -moz-binding: url("chrome://global/content/bindings/toolbarbutton .xml#menu-button"); } // In the XBL file toolbarbutton.xml: <binding id="menu-button" display="xul:menu" extends="chrome://global/content/bindings/button.xm l#menu-button-base"> <resources> <stylesheet src="chrome://global/skin/toolbarbutton.css"/> </resources> <content> <children includes="observes|template|menupopup|tooltip"/> <xul:toolbarbutton class="box-inherit toolbarbutton-menubutton-button" anonid="button" flex="1" allowevents="true" xbl:inherits="disabled,crop,image,label,accessKey,c ommand, align,dir,pack,orient"/> <xul:dropmarker type="menu-button" class="toolbarbutton-menubutton-dropmarker" xbl:inherits="align,dir,pack,orient,disabled"/> </content> </binding> When you use the Modern skin, you can see in Figure 4-10 that the menu button is a composite of the toolbar button, a dropmarker image resource, and a menupopup making the drop-down history available. Figure 4-10. Modern menu button You might also notice in Example 4-13 that this binding pulls in an external stylesheet (toolbarbutton.css), which is contained in the <resources> section of the binding. This stylesheet provides all the styles and theme information for a toolbar button, including the type of menu-button. More information on stylesheets in XBL can be found in Chapter 7 . 4.5.2. User Stylesheets In addition to the many CSS stylesheets that give the user interface its look, Mozilla also lets you create personal stylesheets that apply to all of the chrome and content you view in the browser. Two CSS files, userChrome.css and userContent.css, located in the chrome subdirectory of your user profile, can define rules that apply to all of the Mozilla application interfaces and all web pages you view, respectively. When these two files are present -- sometimes they are installed in the user profile and sometimes you create them yourself -- they come with example rules that are commented out. However, you can uncomment them and add your own rules to personalize the look of the browser and its content. Example 4-14 shows the default commented rules in userChrome.css. Note the use of the !important keyword to specify that these rules should take precedence over rules that come from stylesheets in the current theme. Example 4-14. userChrome.css style rules /* * This file can be used to customize the look of Mozilla's user interface * You should consider using !important on rules which you want to * override default settings. */ /* * example: make the UI look a little more like Irix (nice readable * slanted-helvetical menus, funny pink color on text fields) * * input { * color: black !important; * background-color: rgb(255, 225, 175) !important; * } * * menubar { * font-family: helvetica !important; * font-style: italic !important; * font-weight: bold !important; * font-size: 4mm !important; * } */ /* * For more examples see http://www.mozilla.org/unix/customizing.html */ If you want to make the content in all your menu widgets white so you can read them better, get rid of these defaults and do something like this: menu { background-color: white !important; color: darkblue !important; padding: 5px !important; } You can also use these stylesheets to change or do away with aspects of the user interface you don't like. The following rule, for example, shrinks the navigation buttons in the Modern theme: .toolbarbutton-menubutton-button > .toolbarbutton- box, .toolbarbutton-1 > .toolbarbutton-box [...]... access to XBL bindings Code in the and structures of an XBL binding are ignored, as are event handlers written in the structures You can write these XBL goodies into your theme if you want (or develop a theme out of the Modern theme, where there is plenty of XBL, and see them disabled in your theme when they were working in that preinstalled version), but Mozilla will... will not read or execute them You can use XBL to define new XUL content for a widget by way of CSS, but unless you create an "evil skin," that content has to be simple XUL to show up in your theme at all Evil Skins In the Mozilla community, the term "evil skins" is sometimes used to describe skins with unlimited script access An evil skin is a skin for which the security restrictions above do not apply... the Mozilla services in XPCOM, or implement new application code in XBL widgets Remember that when you develop skins for Mozilla and package them for installation as skins, the script part of your skins will be disabled However, if you create a skin and then install it as a new package, your skin will not be as limited, and you will have full access to XBL, XPConnect, and the script To see how to install... things in XUL that you cannot do in CSS The two preinstalled themes in Mozilla, Modern, and Classic use technologies like XBL, JavaScript, and XPConnect to provide additional behavior to the application They are considered fullblown packages, like entirely separate interfaces (see Chapter 6 for a description the various types of packages and installations) When you install new themes, however, those... can think of the appropriate selectors, you can use userContent .css to change the way banner images are displayed (or not displayed), how basic text is presented, or where certain elements of a web page are positioned 4.5 .3 Theme Security Restrictions To prevent the wholesale overriding of the basic XUL application, various restrictions are placed on themes In other words, you can do some things in XUL... you create a skin and then install it as a new package, your skin will not be as limited, and you will have full access to XBL, XPConnect, and the script To see how to install an evil skin and other new packages in Mozilla, see Chapter 6 . Chapter 4. CSS in Mozilla Applications- P5 4. 4.3. Creating Styles for the xFly Buttons Now that you have created a single custom style for. of CSS in Mozilla. The - moz-binding keyword described in Table 4- 4 is the key to binding special, prefabricated widgets to your XUL. The language in which