Revision Content

The following document outlines rules for optimizing CSS files for use in the Mozilla UI. The first section is a general discussion of how the Mozilla style system categorizes rules. With an understanding of this system, the following sections contain guidelines for writing rules that take advantage of Mozilla's style system implementation.

How the style system breaks up rules

The style system breaks rules up into four primary categories. It is critical to understand these categories, as they are the first line of defense as far as rule matching is concerned. I use the term key selector in the paragraphs that follow. The key selector is defined to be the rightmost occurrence of an id selector, a class selector, or a tag selector.

ID Rules

The first category consists of those rules that have an ID selector as their key selector.

Tag Rules

If no class or ID is specified as the key selector, then the next potential category for a rule is the tag category. If a rule has a tag specified as its key selector, then the rule falls into this category.

How the Style System Matches Rules

The style system matches a rule by starting with the rightmost selector and moving to the left through the rule's selectors. As long as your little subtree continues to check out, the style system will continue moving to the left until it either matches the rule or bails out because of a mismatch.

Your first line of defense is the rule filtering that occurs based on the type of the key selector. The purpose of this categorization is to filter out rules so that you don't even have to waste time trying to match them. This is the key to dramatically increasing performance. The fewer rules that you even have to check for a given element, the faster style resolution will be. As an example, if your element has an ID, then only ID rules that match your element's ID will be checked. Only class rules for a class found on your element will be checked. Only tag rules that match your tag will be checked. Universal rules will always be checked.

Guidelines for Efficient CSS

Avoid Universal Rules!

Make sure a rule doesn't end up in the universal category!

Don't qualify ID-categorized rules with tag names or classes

If you have a style rule that has an ID selector as its key selector, don't bother also adding the tag name to the rule. IDs are unique, so you're slowing down the matching for no real reason.

BAD - button#backButton { }

BAD - .menu-left#newMenuIcon { }

GOOD - #backButton { }

GOOD - #newMenuIcon { }

Don't qualify class-categorized rules with tag names

Similar to the rule above, all of our classes will be unique. The convention you should use is to include the tag name in the class name.

BAD - treecell.indented { }

GOOD - .treecell-indented { }

Try to put rules into the most specific category you can!

The single biggest cause of slowdown in our system is that we have too many rules in the tag category. By adding classes to our elements, we can further subdivide these rules into class categories, and then we no longer waste time trying to match as many rules for a given tag.

Avoid the descendant selector!

The descendant selector is the most expensive selector in CSS. It is dreadfully expensive, especially if a rule using the selector is in the tag or universal category. Frequently what is really desired is the child selector. The use of the descendant selector is banned in UI CSS without the explicit approval of your skin's module owner.

Tag-categorized rules should never contain a child selector!

Avoid using the child selector with tag-categorized rules. You will dramatically increase the matching time (especially if the rule is likely to be matched more often than not) for all occurrences of that element.

BAD - treehead > treerow > treecell { }

BEST - .treecell-header { }

Question all usages of the child selector!

Be careful about using the child selector. If you can come up with a way to avoid having to use it, do so. In particular, the child selector is frequently used with RDF trees and menus like so.

Rely on inheritance!

Learn which properties inherit, and allow them to do so! We have explicitly set up XUL widgetry so that you can put list-style-image (just one example) or font rules on the parent tag, and it will filter in to the anonymous content. You don't have to waste time writing a rule that talks directly to the anonymous content.

BAD - #bookmarkMenuItem > .menu-left { list-style-image: url(blah); }

GOOD - #bookmarkMenuItem { list-style-image: url(blah); }

In the above example, the desire to style the anonymous content (without understanding that list-style-image inherits) resulted in a rule that was in the class category, when this rule really should have ended up being in the most specific category of all, the ID category.

Remember, especially with anonymous content, that they all have the same classes! The bad rule above causes the icon of every menu to be checked to see if it is contained in the bookmarks menu item. This is hideously expensive (since there are many menus); this rule never should have even been checked by any menu other than the bookmarks menu.

Use -moz-image-region!

Putting a bunch of images into a single image file and selecting them with {{template.Cssxref("-moz-image-region")}} performs significantly better than putting each image into its own file.

Original Document Information

Author: David Hyatt

Last Updated Date: 2000-04-21

{{ wiki.languages( { "ja": "ja/Writing_Efficient_CSS" } ) }}

Revision Source

<p>
The following document outlines rules for optimizing CSS files for use in the Mozilla UI. The first section is a general discussion of how the Mozilla style system categorizes rules. With an understanding of this system, the following sections contain guidelines for writing rules that take advantage of Mozilla's style system implementation.
</p>
<h3 name="How_the_style_system_breaks_up_rules"> How the style system breaks up rules </h3>
<p>The style system breaks rules up into four primary categories. It is critical to understand these categories, as they are the first line of defense as far as rule matching is concerned. I use the term <i>key selector</i> in the paragraphs that follow. The key selector is defined to be the rightmost occurrence of an id selector, a class selector, or a tag selector.
</p>
<h4 name="ID_Rules"> ID Rules </h4>
<p>The first category consists of those rules that have an ID selector as their key selector.
</p><p><b>Examples</b>
</p>
<pre class="eval">button#backButton { } /* This is an ID-categorized rule */
#urlBar[type="autocomplete"] { } /* This is an ID-categorized rule */
treeitem &gt; treerow &gt; treecell#myCell :active { } /* This is an ID-categorized rule */
</pre>
<h4 name="Class_Rules"> Class Rules </h4>
<p>If a rule has a class specified as its key selector, then it falls into this category.
</p><p><b>Examples</b>
</p>
<pre class="eval">button.toolbarButton { } /* A class-based rule */
.fancyText { } /* A class-based rule */
menuitem &gt; .menu-left[checked="true"] { } /* A class-based rule */
</pre>
<h4 name="Tag_Rules"> Tag Rules </h4>
<p>If no class or ID is specified as the key selector, then the next potential category for a rule is the tag category. If a rule has a tag specified as its key selector, then the rule falls into this category.
</p><p><b>Examples</b>
</p>
<pre class="eval">td { } /* A tag-based rule */
treeitem &gt; treerow { } /* A tag-based rule */
input[type="checkbox"] { } /* A tag-based rule */
</pre>
<h4 name="Universal_Rules"> Universal Rules </h4>
<p>All other rules fall into this category.
</p><p><b>Examples</b>
</p>
<pre class="eval">:table { } /* A universal rule */
[hidden="true"] { } /* A universal rule */
* { } /* A universal rule */
tree &gt; [collapsed="true"] { } /* A universal rule */
</pre>
<h3 name="How_the_Style_System_Matches_Rules"> How the Style System Matches Rules </h3>
<p>The style system matches a rule by starting with the rightmost selector and moving to the left through the rule's selectors. As long as your little subtree continues to check out, the style system will continue moving to the left until it either matches the rule or bails out because of a mismatch.
</p><p>Your first line of defense is the rule filtering that occurs based on the type of the key selector. The purpose of this categorization is to filter out rules so that you don't even have to waste time trying to match them. This is the key to dramatically increasing performance. The fewer rules that you even have to check for a given element, the faster style resolution will be. As an example, if your element has an ID, then only ID rules that match your element's ID will be checked. Only class rules for a class found on your element will be checked. Only tag rules that match your tag will be checked. Universal rules will always be checked.
</p>
<h3 name="Guidelines_for_Efficient_CSS"> Guidelines for Efficient CSS </h3>
<h4 name="Avoid_Universal_Rules.21"> Avoid Universal Rules! </h4>
<p>Make sure a rule doesn't end up in the universal category!
</p>
<h4 name="Don.27t_qualify_ID-categorized_rules_with_tag_names_or_classes"> Don't qualify ID-categorized rules with tag names or classes </h4>
<p>If you have a style rule that has an ID selector as its key selector, don't bother also adding the tag name to the rule. IDs are unique, so you're slowing down the matching for no real reason.
</p>
<ul><li> BAD - <code>button#backButton { }</code>
</li><li> BAD - <code>.menu-left#newMenuIcon { }</code>
</li><li> GOOD - <code>#backButton { }</code>
</li><li> GOOD - <code>#newMenuIcon { }</code>
</li></ul>
<h4 name="Don.27t_qualify_class-categorized_rules_with_tag_names"> Don't qualify class-categorized rules with tag names </h4>
<p>Similar to the rule above, all of our classes will be unique. The convention you should use is to include the tag name in the class name.
</p>
<ul><li> BAD - <code>treecell.indented { }</code>
</li><li> GOOD - <code>.treecell-indented { }</code>
</li></ul>
<h4 name="Try_to_put_rules_into_the_most_specific_category_you_can.21"> Try to put rules into the most specific category you can! </h4>
<p>The single biggest cause of slowdown in our system is that we have too many rules in the tag category. By adding classes to our elements, we can further subdivide these rules into class categories, and then we no longer waste time trying to match as many rules for a given tag.
</p>
<ul><li> BAD - <code>treeitem{{mediawiki.external('mailfolder=\"true\"')}} &gt; treerow &gt; treecell { }</code>
</li><li> GOOD - <code>.treecell-mailfolder { }</code>
</li></ul>
<h4 name="Avoid_the_descendant_selector.21"> Avoid the descendant selector! </h4>
<p>The descendant selector is the most expensive selector in CSS. It is dreadfully expensive, especially if a rule using the selector is in the tag or universal category. Frequently what is really desired is the child selector. The use of the descendant selector is banned in UI CSS without the explicit approval of your skin's module owner.
</p>
<ul><li> BAD - <code>treehead treerow treecell { }</code>
</li><li> BETTER, BUT STILL BAD (see next guideline) - <code>treehead &gt; treerow &gt; treecell { }</code>
</li></ul>
<h4 name="Tag-categorized_rules_should_never_contain_a_child_selector.21"> Tag-categorized rules should never contain a child selector! </h4>
<p>Avoid using the child selector with tag-categorized rules. You will dramatically increase the matching time (especially if the rule is likely to be matched more often than not) for all occurrences of that element.
</p>
<ul><li> BAD - <code>treehead &gt; treerow &gt; treecell { }</code>
</li><li> BEST - <code>.treecell-header { }</code>
</li></ul>
<h4 name="Question_all_usages_of_the_child_selector.21"> Question all usages of the child selector! </h4>
<p>Be careful about using the child selector. If you can come up with a way to avoid having to use it, do so. In particular, the child selector is frequently used with RDF trees and menus like so.
</p>
<ul><li> BAD - <code>treeitem{{mediawiki.external('IsImapServer=\"true\"')}} &gt; treerow &gt; .tree-folderpane-icon { }</code>
</li></ul>
<p>Remember that attributes from RDF can be duplicated in a template! Take advantage of this fact to duplicate RDF properties on child XUL elements that wish to change based off that attribute.
</p>
<ul><li> GOOD - <code>.tree-folderpane-icon{{mediawiki.external('IsImapServer=\"true\"')}} { }</code>
</li></ul>
<h4 name="Rely_on_inheritance.21"> Rely on inheritance! </h4>
<p>Learn which properties inherit, and allow them to do so! We have explicitly set up XUL widgetry so that you can put list-style-image (just one example) or font rules on the parent tag, and it will filter in to the anonymous content. You don't have to waste time writing a rule that talks directly to the anonymous content.
</p>
<ul><li> BAD - <code>#bookmarkMenuItem &gt; .menu-left { list-style-image: url(blah); }</code>
</li><li> GOOD - <code>#bookmarkMenuItem { list-style-image: url(blah); }</code>
</li></ul>
<p>In the above example, the desire to style the anonymous content (without understanding that list-style-image inherits) resulted in a rule that was in the class category, when this rule really should have ended up being in the most specific category of all, the ID category.
</p><p>Remember, especially with anonymous content, that they all have the same classes! The bad rule above causes the icon of every menu to be checked to see if it is contained in the bookmarks menu item. This is hideously expensive (since there are many menus); this rule never should have even been checked by any menu other than the bookmarks menu.
</p>
<h4 name="Use_-moz-image-region.21"> Use -moz-image-region! </h4>
<p>Putting a bunch of images into a single image file and selecting them with {{template.Cssxref("-moz-image-region")}} performs significantly better than putting each image into its own file.
</p>
<div class="originaldocinfo">
<h3 name="Original_Document_Information"> Original Document Information </h3>
<ul><li> Author: David Hyatt
</li><li> Last Updated Date: 2000-04-21
</li></ul>
</div>
{{ wiki.languages( { "ja": "ja/Writing_Efficient_CSS" } ) }}