Cascade and inheritance
You are probably wondering what exactly cascades about cascading style sheets. In this section we look at the idea of cascading, and a related idea, that of inheritance. Both are important underlying concepts that you will need to grasp, and understand the difference between, in order to work properly with style sheets.
A single style sheet associated with one or more web pages is valuable, but in quite a limited way. For small sites, the single style sheet is sufficient, but for larger sites, especially sites managed by more than one person (perhaps several teams who may never communicate) single style sheets don't provide the ability to share common styles, and extend these styles where necessary. This can be a significant limitation.
Cascading style sheets are unlike the style sheets you might have worked with using word processors, because they can be linked together to create a hierarchy of related style sheets. This process of linking is called cascading, for reasons we will look at in just a moment. Before we do, let's look at why cascading is such a good idea.
Imagine how the web site for a large organization, say a corporation, might be structured. As sites grow in complexity, individual divisions, departments, and workgroups become more responsible for their own section of a site. We can already see a potential problem - how do we ensure a consistent look and feel across the whole site?
A dedicated web development team can ensure that a style guide is adhered to. How can we ensure that each workgroup, department, and division also follows the guidelines? Won't the site end up as a dog's breakfast of mish mashed styles?
With traditional HTML, the answer is almost certainly yes. Individual style sheets make life a little better, as all of the style information is concentrated in a single location, easily edited and reviewed. However, we still have the organizational difficulty of ensuring that each style sheet is the same as all the others, that the latest version has been distributed to all and updated.
Then there is the logistical nightmare of trying to have each and every style needed by every group included in the one style sheet. Different departments and groups have different needs - the legal department will have different needs from the engineering department, but they will share the basic look and feel of the company's site.
This doesn't look promising. But Cascading Style Sheets in fact provide a mechanism, the cascade, which helps address these very problems.
Cascading style sheets do not have to stand alone. They can import style from one or more other style sheets. Style sheets which import from others are said to cascade from those style sheets.
Here is how we might use the cascading nature of style sheets to help solve the organizational nightmare we described above.
At the top level, the company could have a core style sheet, which defines the basic look and feel for the corporate site. It might include aspects such as font, color, background color and so on.
Each division would have a divisional style sheet. This does not have to reproduce the core style sheet, simply to add any styles specific to the division. To ensure that this style sheet also carries the core styles, it only has to import the core style sheet. It can do this simply be including an @import rule.
We can continue down the chain, with each new style sheet adding styles necessary at that level, and importing the style sheet above (there is no need to import all style sheets, as importing a style sheet imports any style sheets imported by that style sheet.)
Using the process, we create a cascade of style sheets. When a style sheet above another in the cascade is changed, these changes cascade automatically into the web pages which are linked to the lower one too. Our organizational nightmare is easily managed using the cascading nature of style sheets.
At this point it might be timely to have a quick discussion of specificity. Both inside a single style sheet, and in a cascade of style sheets, it should be clear that more than one rule can apply to the same element. What happens when two properties in separate rules which both apply to an element contradict one another? Obviously they can't both apply (the text of an element can't be both red and blue, for example). CSS provides a mechanism for resolving these conflicts, called specificity.
Some selectors are more specific than others. For example, the class and ID selectors are more specific than simple HTML element selectors. When two rules select the same element and the properties contradict one another, the rule with the more specific selector takes precedence. Specificity for selectors is a little involved. Without going into the full detail, most situations can be resolved with the following rules.
- ID selectors are more specific than other selectors
- Class selectors are more specific than HTML element selectors, and other selectors such as contextual, pseudo class and pseudo element selectors.
- Contextual selectors, and other selectors involving more than one HTML element selector are more specific than a single element selector (and for two multiple element selectors, the one with more elements is more specific than the one with fewer.)
There are times though when the two rules will have the same specificity. In this case, the rule that comes later in the cascade prevails.
I started using it as a learning tool, assuming I would go back to editing my CSS in my text editor - but it is just so convenient.
For example, where one rule is in an imported style sheet, and the other in the style sheet itself, the rule in the style sheet which is importing takes precedence. When the two rules are in the same style sheet, it is the one furthest from the top of the style sheet that takes precedence.
While these rules seem complicated at first, they are pretty much common sense, and it is uncommon that much confusion or difficulty arises for a developer.
Any HTML page comprises a number of (perhaps a large number of) elements - headings, paragraphs, lists, and so on. Often, developers use the term "tag" to refer to an element, making reference for example to "the p tag". But the tag is simply the
<p></p> part of the element. The whole construction of
<p>This is the content of the paragraph</p> is in fact the
<p> element (as we refer to it in this guide). What many web developers don't realize (largely because it wasn't particularly important until style sheets came along) is that every element is contained by another element, and may itself contain other elements. The technical term for this is the containment hierarchy of a web page.
At the top of the containment hierarchy is the
<html> element of the page. Every other element on a web page is contained within the
<html> element, or one of the elements contained within it, and so on. Similarly, many elements will be contained in paragraphs, while paragraphs are contained in the
Graphically, we can understand it like this.
figure 4: the HTML containment hierarchy
I said above that style sheets made it important to understand this. Why? Well, with cascading style sheets, elements often (and with CSS2 can always be forced to) inherit properties from the elements which contain them (otherwise known as their parent elements). This means that if you give the body of the page certain properties (for example font and color) then every element within the page will inherit these properties- there is no need to set the font and color again for each element, such as list items or paragraphs.
You can always override the inheritance however. By assigning a property to an element, you override the inherited property.