Diff for /books/www/chapters/ch04.html between versions 1.1 and 1.2

version 1.1, 2002/09/17 21:10:35 version 1.2, 2002/09/23 15:23:31
Line 2 Line 2
 <HEAD><TITLE>Chapter 4</TITLE></HEAD><BODY BGCOLOR=WHITE><H2>Chapter 4</H2>  <HEAD><TITLE>Chapter 4</TITLE></HEAD><BODY BGCOLOR=WHITE><H2>Chapter 4</H2>
 <H1><A NAME="77060"></A> CSS in Mozilla Applications</H1>  <H1><A NAME="77060"></A> CSS in Mozilla Applications</H1>
 <P>This chapter describes how Cascading Style Sheets (CSS) are used to create the look and feel of a Mozilla application's interface. Although XUL has a central role in creating a structure for an application's interface, defining widgets and their functionality, and creating the basic application code, it is CSS that creates the visible portion of an application. XUL and CSS often work so closely together that they seem inseparable, but XUL is generally responsible for the structure of an application's interface and CSS is responsible for the application's presentation. As described in the next sections, it is not until an XPFE application has been "skinned," or styled with stylesheets, that it has a usable interface.  <P>This chapter describes how Cascading Style Sheets (CSS) are used to create the look and feel of a Mozilla application's interface. Although XUL has a central role in creating a structure for an application's interface, defining widgets and their functionality, and creating the basic application code, it is CSS that creates the visible portion of an application. XUL and CSS often work so closely together that they seem inseparable, but XUL is generally responsible for the structure of an application's interface and CSS is responsible for the application's presentation. As described in the next sections, it is not until an XPFE application has been "skinned," or styled with stylesheets, that it has a usable interface.
<P>The first few sections in this chapter provide basic information about using CSS and some examples of how the Mozilla interface is created. They include reference material you can refer back to as you learn more. Starting with the "Creating New Skins" section, you can dive in, have some fun with CSS, and begin to create your own skins. The xFly package example created earlier in the book shows how to add custom styles to the XUL files you created in Chapters <A HREF="ch02.htm#68959">2</A> and <A HREF="ch03.htm#32764">3</A>.<P>The first few sections in this chapter provide basic information about using CSS and some examples of how the Mozilla interface is created. 
 They include reference material you can refer back to as you learn more. Starting with the "Creating New Skins" section, you can dive in, have 
 some fun with CSS, and begin to create your own skins. The xFly package example created earlier in the book shows how to add custom styles to the XUL files you created in Chapters <A HREF="ch02.html#68959">2</A> and <A HREF="ch03.html#32764">3</A>.
 <H2><A NAME="77061"></A> Interface Basics</H2>  <H2><A NAME="77061"></A> Interface Basics</H2>
 <P>Before describing the  <!--INDEX interfaces:(see also user interface)[interfaces:zz(see also user interface)] -->  <!--INDEX user interface:overview;UI (see user interface) --> practice of using  <!--INDEX CSS (Cascading Style Sheets):user interfaces --> CSS, let's get some basic theory out of the way. When we talk about the interface of an application, we mean all of the parts of the application that are displayed and allow the user to interact. Buttons, windows, pages, menus, sliders, and descriptive text are all parts of the interface. In Mozilla, XUL usually defines the basic structure of the interface and CSS defines its presentation. These two aspects of the interface-the way it's organized and the way it's presented-are kept as distinct from one another as possible in Mozilla and in many good programming environments. Indeed, this separation is what gives rise to the concept of  <!--INDEX skins -->  <!--INDEX user interface:skins --> skins-coherent, separate, and typically swappable "looks" for the same underlying structure. Mozilla uses Cascading Style Sheets, a quickly evolving series of standards already common in HTML web page presentation, to define the skin of XUL application interfaces.  <P>Before describing the  <!--INDEX interfaces:(see also user interface)[interfaces:zz(see also user interface)] -->  <!--INDEX user interface:overview;UI (see user interface) --> practice of using  <!--INDEX CSS (Cascading Style Sheets):user interfaces --> CSS, let's get some basic theory out of the way. When we talk about the interface of an application, we mean all of the parts of the application that are displayed and allow the user to interact. Buttons, windows, pages, menus, sliders, and descriptive text are all parts of the interface. In Mozilla, XUL usually defines the basic structure of the interface and CSS defines its presentation. These two aspects of the interface-the way it's organized and the way it's presented-are kept as distinct from one another as possible in Mozilla and in many good programming environments. Indeed, this separation is what gives rise to the concept of  <!--INDEX skins -->  <!--INDEX user interface:skins --> skins-coherent, separate, and typically swappable "looks" for the same underlying structure. Mozilla uses Cascading Style Sheets, a quickly evolving series of standards already common in HTML web page presentation, to define the skin of XUL application interfaces.
 <H3><A NAME="77062"></A> Skins Versus Themes</H3>  <H3><A NAME="77062"></A> Skins Versus Themes</H3>
Line 50  win Line 52  win
 platformDialogOverlay.xul</PRE>  platformDialogOverlay.xul</PRE>
 <P>These platform-specific files allow the application developer to write XUL that works the same way on every platform, but preserves subtler aspects of an interface that users expect from their <!--INDEX ENDRANGE--user interface:design issues, cross-platform considerations -->  <!--INDEX ENDRANGE--design issues, user interfaces:cross-platform considerations -->   <!--INDEX ENDRANGE--Cross-Platform:interface considerations --> platform.  <P>These platform-specific files allow the application developer to write XUL that works the same way on every platform, but preserves subtler aspects of an interface that users expect from their <!--INDEX ENDRANGE--user interface:design issues, cross-platform considerations -->  <!--INDEX ENDRANGE--design issues, user interfaces:cross-platform considerations -->   <!--INDEX ENDRANGE--Cross-Platform:interface considerations --> platform.
 <H2><A NAME="77066"></A> Introduction to CSS in Mozilla</H2>  <H2><A NAME="77066"></A> Introduction to CSS in Mozilla</H2>
<P>Now that you have absorbed some of the most important basic aspects of interface design, we can begin to discuss how Mozilla uses CSS and images to make actual interfaces out of the structure defined in the XUL files. Though XUL contains the widgets and structure upon which the interface rests, it is not until at least some basic skin information has been loaded into the XUL that the interface becomes visible and editable by the user. In addition to this, CSS binds XBL widgets to the basic structure of the XUL code, allowing extended content to appear in your document. For more information about XBL, see <A HREF="ch07.htm#70326">Chapter 7</A>.<P>Now that you have absorbed some of the most important basic aspects of interface design, we can begin to discuss how Mozilla uses CSS and 
 images to make actual interfaces out of the structure defined in the XUL files. Though XUL contains the widgets and structure upon which the interface rests, it is not until at least some basic skin information has been loaded into the XUL that the interface becomes visible and editable by the user. In addition to this, CSS binds XBL widgets to the basic structure of the XUL code, allowing extended content to appear in your document. For more information about XBL, see <A HREF="ch07.html#70326">Chapter 7</A>.
 <H3><A NAME="77067"></A> Basic XUL + CSS Interaction</H3>  <H3><A NAME="77067"></A> Basic XUL + CSS Interaction</H3>
 <P>XUL and CSS interact at two basic levels in Mozilla. At the file level, XUL picks up CSS information by explicitly loading CSS stylesheets at runtime. At the element level, selectors bind CSS rules to specific XUL elements or groups of elements. For an XUL element to pick up a style defined in a CSS file, the XUL file must load the CSS file, and an element or group of elements in the XUL must match a selector in the CSS rule. We discuss these basic levels of interaction in the following two sections.  <P>XUL and CSS interact at two basic levels in Mozilla. At the file level, XUL picks up CSS information by explicitly loading CSS stylesheets at runtime. At the element level, selectors bind CSS rules to specific XUL elements or groups of elements. For an XUL element to pick up a style defined in a CSS file, the XUL file must load the CSS file, and an element or group of elements in the XUL must match a selector in the CSS rule. We discuss these basic levels of interaction in the following two sections.
 <H4><A NAME="77068"></A> CSS and XUL file interaction</H4>  <H4><A NAME="77068"></A> CSS and XUL file interaction</H4>
Line 367  background-color: inherit; Line 370  background-color: inherit;
 <I>Classic and Modern Navigation toolbars</I>  <I>Classic and Modern Navigation toolbars</I>
   
 <P>Both themes are complete. They each contain all skin resources for the major components of the application.<A NAME="b290"></A><A HREF="#290">[*]</A> The resources themselves vary, but their structures are almost identical. This ability is what makes the skins dynamically changeable.  <P>Both themes are complete. They each contain all skin resources for the major components of the application.<A NAME="b290"></A><A HREF="#290">[*]</A> The resources themselves vary, but their structures are almost identical. This ability is what makes the skins dynamically changeable.
<P>Skin developers can, for example, create a skin for a single component in Mozilla (e.g., messenger) and let the Modern theme continue to take care of the other components for which they have not created any new CSS information. Which components are skinned by which themes is specified in the <I>installed-chrome.txt</I> file, where a single entry represents the application of the appropriate theme resources to a single component, such as navigator. (See <A HREF="ch06.htm#15291">Chapter 6</A> for more information about this file and about how themes and other packages are registered and applied in Mozilla.) This situation does not apply to new applications like xFly, however, for which the XUL is typically a single package and the CSS that applies to it is another single package. Unlike the Mozilla browser, your application will probably have a single manifest and <I>content</I> subdirectory and a single manifest and <I>skin</I> subdirectory:<P>Skin developers can, for example, create a skin for a single component in Mozilla (e.g., messenger) and let the Modern theme continue to take 
 care of the other components for which they have not created any new CSS information. Which components are skinned by which themes is specified in the <I>installed-chrome.txt</I> file, where a single entry represents the application of the appropriate theme resources to a single component, such as navigator. (See <A HREF="ch06.html#15291">Chapter 6</A> for more information about this file and about how themes and other packages are registered and applied in Mozilla.) This situation does not apply to new applications like xFly, however, for which the XUL is typically a single package and the CSS that applies to it is another single package. Unlike the Mozilla browser, your application will probably have a single manifest and <I>content</I> subdirectory and a single manifest and <I>skin</I> subdirectory:
 <PRE>xfly.jar:  <PRE>xfly.jar:
 content/  content/
 contents.rdf  contents.rdf
Line 518  contents.rdf Line 522  contents.rdf
  }</PRE>   }</PRE>
   
 <H2><A NAME="77095"></A> Creating New Skins</H2>  <H2><A NAME="77095"></A> Creating New Skins</H2>
<P>You have  <!--INDEX skins:creating --> already created the highest level of the directory structure you will need to create a skin for the xFly application (See "Creating the Hello xFly Package" in <A HREF="ch02.htm#77048">Chapter 2</A>). So far, you have created three subdirectories corresponding to different parts of the package and you have added XUL to the <I>xfly/content </I>subdirectory. In the <I>xfly/skin</I> subdirectory, you will tell the xFly content where to expect to find its skin resources. As just mentioned, Mozilla applications outside of the browser itself typically restrict their skin to a single subdirectory and their skin manifest to a single RDF/XML file.<P>You have  <!--INDEX skins:creating --> already created the highest level of the directory structure you will need to create a skin for the xFly 
 application (See "Creating the Hello xFly Package" in <A HREF="ch02.html#77048">Chapter 2</A>). So far, you have created three subdirectories corresponding to different parts of the package and you have added XUL to the <I>xfly/content </I>subdirectory. In the <I>xfly/skin</I> subdirectory, you will tell the xFly content where to expect to find its skin resources. As just mentioned, Mozilla applications outside of the browser itself typically restrict their skin to a single subdirectory and their skin manifest to a single RDF/XML file.
 <P>Since the <I>skin</I> subdirectory in your xFly package is already registered, you can create a new CSS file called <I>xfly.css</I>, save it in the <I>skins </I>subdirectory, and load it from your <I>xfly.xul</I> file by adding the following stylesheet loading instruction at the top:  <P>Since the <I>skin</I> subdirectory in your xFly package is already registered, you can create a new CSS file called <I>xfly.css</I>, save it in the <I>skins </I>subdirectory, and load it from your <I>xfly.xul</I> file by adding the following stylesheet loading instruction at the top:
 <PRE>&lt;?xml-stylesheet href="chrome://xfly/skin" type="text/css" ?&gt;</PRE>  <PRE>&lt;?xml-stylesheet href="chrome://xfly/skin" type="text/css" ?&gt;</PRE>
 <P>You will recall that the chrome pointer in the <I>href</I> resolves to a file named <I>xfly.css</I> (named after the directory) in the following <I>registered</I> directory in the chrome:  <P>You will recall that the chrome pointer in the <I>href</I> resolves to a file named <I>xfly.css</I> (named after the directory) in the following <I>registered</I> directory in the chrome:
Line 592  Example 4-10<A NAME="77048"></A> Line 597  Example 4-10<A NAME="77048"></A>
  }</PRE>   }</PRE>
   
 <H3><A NAME="77099"></A> Describing the Skin in RDF</H3>  <H3><A NAME="77099"></A> Describing the Skin in RDF</H3>
<P>As described  <!--INDEX skins:creating:RDF manifest files -->  <!--INDEX RDF (Resource Description Framework):files:creating skins -->  <!--INDEX manifests:creating skins -->  <!--INDEX files:mainfest, creating skins --> in <A HREF="ch06.htm#15291">Chapter 6</A>, a manifest must accompany and describe the skin so it can be found and registered. The manifest is an RDF file called <I>contents.rdf</I> that sits at the highest level of the skin (i.e., at the top of the JAR or immediately under the <I>modern</I> directory when extracted to disk). Since the content, skin, and locale of an application are considered different packages, each must have its own manifest.<P>As described  <!--INDEX skins:creating:RDF manifest files -->  <!--INDEX RDF (Resource Description Framework):files:creating skins -->  
 <!--INDEX manifests:creating skins -->  <!--INDEX files:mainfest, creating skins --> in <A HREF="ch06.html#15291">Chapter 6</A>, a manifest must accompany and describe the skin so it can be found and registered. The manifest is an RDF file called <I>contents.rdf</I> that sits at the highest level of the skin (i.e., at the top of the JAR or immediately under the <I>modern</I> directory when extracted to disk). Since the content, skin, and locale of an application are considered different packages, each must have its own manifest.
 <P>The listing in <A HREF="#77050">Example 4-11</A> shows the <I>contents.rdf</I> manifest that accompanies the xFly skin resources in the <I>xfly.jar!/skin/</I> directory.  <P>The listing in <A HREF="#77050">Example 4-11</A> shows the <I>contents.rdf</I> manifest that accompanies the xFly skin resources in the <I>xfly.jar!/skin/</I> directory.
   
 Example 4-11<A NAME="77050"></A>  Example 4-11<A NAME="77050"></A>
Line 637  Example 4-12<A NAME="77052"></A> Line 643  Example 4-12<A NAME="77052"></A>
 <H2><A NAME="77100"></A> What Is Possible in a Skin?</H2>  <H2><A NAME="77100"></A> What Is Possible in a Skin?</H2>
 <P>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.  <P>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.
 <H3><A NAME="77101"></A> Binding New Widgets to the Interface Using XBL</H3>  <H3><A NAME="77101"></A> Binding New Widgets to the Interface Using XBL</H3>
<P>A  <!--INDEX CSS (Cascading Style Sheets):widgets, binding with XBL -->  <!--INDEX widgets:binding with XBL -->  <!--INDEX skins:widgets, binding with XBL -->  <!--INDEX bindings:XBL:widgets -->  <!--INDEX XBL (eXtensible Binding Language):widgets --> 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 <TT>-moz-binding</TT> keyword described in <A HREF="#77028">Table 4-4</A> 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. <A HREF="ch07.htm#77027">Chapter 7</A> describes this language in more detail.<P>A  <!--INDEX CSS (Cascading Style Sheets):widgets, binding with XBL -->  <!--INDEX widgets:binding with XBL -->  <!--INDEX skins:widgets, 
 binding with XBL -->  <!--INDEX bindings:XBL:widgets -->  <!--INDEX XBL (eXtensible Binding Language):widgets --> 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 <TT>-moz-binding</TT> keyword described in <A HREF="#77028">Table 4-4</A> 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. <A HREF="ch07.html#77027">Chapter 7</A> describes this language in more detail.
 <P>To see how XBL works, go back and look at the first style rule for "print-button" in <A HREF="#77040">Example 4-6</A>. The first style statement in that block has a property called <TT>-moz-</TT> <TT>binding</TT>. This property defines a <I>binding</I> for the XUL element styled by this style rule. The <I>chome URL</I> that the <TT>-moz-binding</TT> property points to is where an XBL-based definition of a print button is located.  <P>To see how XBL works, go back and look at the first style rule for "print-button" in <A HREF="#77040">Example 4-6</A>. The first style statement in that block has a property called <TT>-moz-</TT> <TT>binding</TT>. This property defines a <I>binding</I> for the XUL element styled by this style rule. The <I>chome URL</I> that the <TT>-moz-binding</TT> property points to is where an XBL-based definition of a print button is located.
 <P>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 <TT>-moz-binding</TT> 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 <TT>&lt;content&gt;</TT> and <TT>&lt;handlers&gt;</TT> child elements) in which you can define new XUL content, new JavaScript, and new XPConnected interfaces. CSS glues the XUL together with the XBL.  <P>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 <TT>-moz-binding</TT> 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 <TT>&lt;content&gt;</TT> and <TT>&lt;handlers&gt;</TT> child elements) in which you can define new XUL content, new JavaScript, and new XPConnected interfaces. CSS glues the XUL together with the XBL.
 <P>In the first part of the snippet in <A HREF="#77054">Example 4-13</A>, for example, the CSS rule binds the toolbar button to an XBL binding called <I>menu-button</I>, which adds a button and an image.  <P>In the first part of the snippet in <A HREF="#77054">Example 4-13</A>, for example, the CSS rule binds the toolbar button to an XBL binding called <I>menu-button</I>, which adds a button and an image.
Line 671  Example 4-13<A NAME="77054"></A> Line 678  Example 4-13<A NAME="77054"></A>
 Figure 4-10<A NAME="77020"></A>  Figure 4-10<A NAME="77020"></A>
 <I>Modern menu button</I>  <I>Modern menu button</I>
   
<P>You might also notice in <A HREF="#77054">Example 4-13</A> that this binding pulls in an external stylesheet (<TT>toolbarbutton.css</TT>), which is contained in the <TT>&lt;resources&gt;</TT> section of the binding. This stylesheet provides all the styles and theme information for a toolbar button, including the type of <TT>menu-button</TT>. More information on stylesheets in XBL can be found in <A HREF="ch07.htm#70326">Chapter 7</A>.<P>You might also notice in <A HREF="#77054">Example 4-13</A> that this binding pulls in an external stylesheet (<TT>toolbarbutton.css</TT>), 
 which is contained in the <TT>&lt;resources&gt;</TT> section of the binding. This stylesheet provides all the styles and theme information for a toolbar button, including the type of <TT>menu-button</TT>. More information on stylesheets in XBL can be found in <A HREF="ch07.html#70326">Chapter 7</A>.
 <H3><A NAME="77102"></A> User Stylesheets</H3>  <H3><A NAME="77102"></A> User Stylesheets</H3>
 <P>In  <!--INDEX user stylesheets -->  <!--INDEX stylesheets:user -->  <!--INDEX CSS (Cascading Style Sheets):user stylesheets -->  <!--INDEX userChrome.css -->  <!--INDEX userContent.css --> 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, <I>userChrome.css</I> and <I>userContent.css</I>, located in the <I>chrome</I> 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.  <P>In  <!--INDEX user stylesheets -->  <!--INDEX stylesheets:user -->  <!--INDEX CSS (Cascading Style Sheets):user stylesheets -->  <!--INDEX userChrome.css -->  <!--INDEX userContent.css --> 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, <I>userChrome.css</I> and <I>userContent.css</I>, located in the <I>chrome</I> 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.
 <P><A HREF="#77056">Example 4-14</A> shows the default commented rules in <I>userChrome.css</I>. Note the use of the <TT>!important</TT> keyword to specify that these rules should take precedence over rules that come from stylesheets in the current theme.  <P><A HREF="#77056">Example 4-14</A> shows the default commented rules in <I>userChrome.css</I>. Note the use of the <TT>!important</TT> keyword to specify that these rules should take precedence over rules that come from stylesheets in the current theme.
Line 718  text-align: center !important; Line 726  text-align: center !important;
 }</PRE>  }</PRE>
 <P>Or, if you can think of the appropriate selectors, you can use <I>userContent.css</I> 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.  <P>Or, if you can think of the appropriate selectors, you can use <I>userContent.css</I> 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.
 <H3><A NAME="77103"></A> Theme Security Restrictions</H3>  <H3><A NAME="77103"></A> Theme Security Restrictions</H3>
<P>To prevent  <!--INDEX themes:security considerations -->  <!--INDEX security:themes --> 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 <A HREF="ch06.htm#15291">Chapter 6</A> 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.<P>To prevent  <!--INDEX themes:security considerations -->  <!--INDEX security:themes --> 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 <A HREF="ch06.html#15291">Chapter 6</A> 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.
 <P>Code in the <TT>&lt;implementation&gt;</TT> and <TT>&lt;handler&gt;</TT> structures of an XBL binding are ignored, as are event handlers written in the <TT>&lt;content&gt;</TT> structures.  <P>Code in the <TT>&lt;implementation&gt;</TT> and <TT>&lt;handler&gt;</TT> structures of an XBL binding are ignored, as are event handlers written in the <TT>&lt;content&gt;</TT> structures.
 <P>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.  <P>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.
 <BLOCKQUOTE><HR><A NAME="62192"></A> Evil Skins  <BLOCKQUOTE><HR><A NAME="62192"></A> Evil Skins
 <P>In the  <!--INDEX evil skins -->  <!--INDEX skins:evil skins --> 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.  <P>In the  <!--INDEX evil skins -->  <!--INDEX skins:evil skins --> 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.
<P>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 <A HREF="ch06.htm#15291">Chapter 6</A>.<HR></BLOCKQUOTE><P>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 <A HREF="ch06.html#15291">Chapter 6</A>.<HR></BLOCKQUOTE>
   
 <HR>  <HR>
 <HR><A NAME="290"></A><A HREF="#b290">[Back]</A>  <HR><A NAME="290"></A><A HREF="#b290">[Back]</A>

Removed from v.1.1  
changed lines
  Added in v.1.2


FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>