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

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 ele

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:

menubutton-button > .toolbarbutton-box,

.toolbarbutton-1 > toolbarbutton-box

{

max-width: 40px !important;

text-align: center !important;

}

Or, if you 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 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 full-blown 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 themes do not have "script access" and have limited access to XBL bindings

Code in the <implementation> and <handler> structures of an XBL binding are ignored, as are event handlers written in the <content>

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 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 They can access the DOM of the web page and XUL content, use XPConnect to connect to 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 an evil skin and other new packages in Mozilla, see

Chapter 6