More advice for the full screen mode.
I list below all topic groups, which I have done according to subjects, which they handle. You can return to this topic group by using this menu and the link Table of topic groups on the top of the each page.
To the normal page

5. What is the processing order of CSS


I have divided this page into sections, which handle following topics:

The content as a one big page


In order to construct CSS-files it is necessary to understand, in which order browsers should read CSS-properties.


In principle there are three types of style sheets:

  1. UA style sheets (UA = User Agent = browser or other application, which use style sheets). In question is primary about the own definitions of applications, if there is not any style sheet defined. In fact this means primary understanding of ordinary HTML 3.2 or HTML 4.0 level elements and attributes. Browsers have a little bit different default settings. Browsers can also support some CSS-properties, which can use in all Web-pages. It is possible to define in MS IE 5.x+ to links the property hover. It has the same meaning as the pseudo-class :hover. Saved definitions creates a certain kind of UA style sheet. Mozilla Gecko browsers use actual UA CSS, because they define default HTML-setting by CSS in /res/html.css and /res/html.css (also Opera use UA CSS in non-HTML implementations; I handle UA CSS related properties in an extra page[S]). Own default settings of browsers are used, if any CSS-properties are not especially defined.

    In general other way defined CSS-properties override UA style sheets and HTML-attributes. There are however some exceptions, which I tell in another connections. In the rules, how browsers override HTML-attributes, are some differences between browsers. Authors should know them, if they want to create pages, which look out as much as possible the same in various browsers.
  1. User style sheets. They mean style sheets, which the user creates to the user agent. It is in theory possible to create CSS-properties to all wow-documents by feeding the path of the CSS-file to the UA (I handle the usage of user style sheets in an extra page[S]).
  1. Author style sheets. Those means just all CSS, which the author has defined to the document. The relation of the author style sheets to the users style sheet is in practise user agent dependent. In principle this relation can be controlled with the important rule. By using that rule some individual properties can be set to have an exceptional weight (I explain the usage more thoroughly at the end of this page). According to the CSS1 the priority is author style sheet and according to CSS2 user style sheets.
W3C: CSS2: 6.4.2 !important rules[S][Pw].


Basic ideas


Basic metaphors

Browsers interpret all definition by certain rules. Most of rules base on the document tree. Besides the tree metaphor in the computer language is used the family and kinship metaphor. We talk about for example parents and child. A parent element might have required and then also in a way "natural" children (child elements can be also non-necessary).

This relationship describes a simple document tree:

BODY  - H1 (this element don't have any natural child)
- P
- OL (an ordered list, which must have at least one child-element )
LI (individual list-element, which is the necessary child of the element OL)
LI (another list-element ; list-elements can have many level of sub-lists and then OL can have "grandchildren")

Most of the rules are named using the family metaphor. It is also remarkable that rules handle element levels, nested elements and bilateral relationships of individual elements in the document tree (this model works partially also with attribute selectors, but as I have told, attribute selectors don't work today in official browsers). I handle also in this connection the :first-child pseudo-class selector, because it is a part of whole system. It can be understand only in connection to other relationships. I try to explain everything as grass-root level as I can! Parts of the metaphor are:

  • Parent = parent level element. When we write about parent, the parent must have at least one child-level element. We must remark, that only the next sub-level elements are children. Parent is the direct surrounding element and between parent and children are not other element levels.
    Hen and chicken
  • Child = any child-level element, which have a direct parent-level element. A child is a part element of the parent level element.
  • First-child = the next level element after the parent level element (in the case of :first-child an individual element)
  • Ancestor = any element, which has inside it another elements. Partially the same as parent, but there can be several nested element levels between elements.
  • Descendant = any element, which is inside another elements. Partially the same as child, but there can be several nested element levels between elements. "Grandchildren" are always descendant elements.
  • Adjacent sibling = sibling level elements have the same parent and elements are not nested with each others. They are in parallel relationship to each others like sisters and brothers. An adjacent sibling is the next at same level being element level after the first mentioned element in the same level. CSS2 uses also more exact terms, which are listed below and they are related to the adjacent sibling.
    • The preceding sibling. The adjacent sibling definition gives only the element level. In the family is single first-born and after him becomes other children. In order to name the first-born, it must have pseudo-class :first-child. The preceding sibling is just the first-born, who is preceding before other siblings.
    • The following sibling. Some other siblings in the same "element family".
    • The preceding element. The element, which is a previous element or in the previous element level as the adjacent sibling.
    • Following element. The opposite relationship to the previous.
W3C: CSS2: 3 Conformance: Requirements and Recommendations[Pw].



In family children inherit their parents and descendant got his inheritance from his ancestor. It is essential to understand inheriting rules and the mechanism, which is called inheritance. Inheritance means the automatic mechanism, how properties are applied into elements. The principle concerns nested elements, which are parts of the document tree[S][Pw].

The inheritance of properties, which are give to the BODY-element works fine with certain block elements and their necessary child-elements. Automatic inherited properties are primary most font and text types.

Elements, which effect to the text, like H1-H6, B and I retain in variable level their characteristic features. H1-H6 keeps their relative sizes compared to the basic text, but most text style definitions are inherited from the element BODY. Some text elements retain their features even if CSS to BODY has defined. The reason why some font-related properties are not inherited to all possible elements is the fact that some elements have been predefined in the default settings of the browsers. The quantity of predefined elements is browser-dependent. Because of this reason some browsers need more CSS than some other browsers. In some browsers inheritance doesn't work correctly, but I handle some difficulties later.

All properties like background properties are not inherited from parent to child (in the appendix of CSS2 specifications is a table, which tells, which properties are inherited and which not). Children are in that means independent, that they can get own definitions.

Into the CSS specification has been added the value inherit (like TABLE {color:inherit;}), which means that all definitions are inherited from closest parent element. This is certain kind of "forced inheritance".

Browser-specific notes:

  1. I don't recommend to use the value inherit, because many browsers, which in other matters handle quite well CSS, don't support it. In my tests it has worked only in Mozilla 0.7 and Mozilla 1.1a but not in all relative Mozilla Gecko browsers.

W3C: CSS2: Appendix F. Property index[Pw].


Matching patterns and contextual selectors

The automatic inheritance principle concerns only necessary or natural relationships. I mean with the natural relationship, that some elements are designed to have many level of nested elements like ordered and unordered lists. Sub-lists inherit CSS-properties from their nearest parents. The automatic inheritance can create only generic guidelines. In order to get better control it is possible to create matching rules. Different selectors create like "patterns" and browsers try to find, where patterns could match. The whole system is pattern matching and I would call individual cases as matching patterns.

Because the meaning of matching patterns is to create rules to individual cases, the CSS1 specification write about contextual What are selectors, classes and id-attributes, which term is not used in the CSS2 specification, because relations are expressed using words descendants, ancestors etc. In my mind is is good to write also about contextual selectors.

Contextual selectors or matching patterns base primary on the bilateral relationships of elements and the relationships are described with the family metaphor. On the background of this method is also the document tree. But otherwise than in the automatic inheritance, pattern matching works like key and keyhole principle. According to the name they take account the context. Certain style is applied only to elements, which are in the right place or they have certain parent element.

In fact a simple universal or element type selector is a matching pattern. In order to separate simple selectors from complex selectors, I mean as matching patterns those kinds of rules, which have at least two conditions. An example of a very simple matching pattern ([M][S][Pw]):

table p {color:green;} /* the latter condition is called as descendant selector; in these kinds of patterns, it is remarkable, that the left round bracket ({) must be in the same row as the pattern, because I have found that patterns don't work if it is another row */

According to this rule, all paragraphs, which are inside tables and then are descendants of the element TABLE, got the property color:green (paragraphs are inside the start-tag and end-tag of the element TD).

I use often these kinds of matching patterns, when I define list-images to unordered lists (UL). If you use grouping[S][Pw], you can create with same declaration exact properties to several level of lists. Below is an example of this kind of solution ([M][S][Pw] - there is also models of the next examples):

ul li, ul li li li { /* in this example I have is defined first and third level lists and they get green list-images (I explain in other connection allowed properties for lists) */
list-style-type: disc;
list-style-image: url(pallo-vihrea.gif); /* vihrea = green */
list-style-position: inside;
margin-left: -10px; }

ul li li { /* according to this rule, second level lists got red list-image; if this list-marker is not defined, it gets the value from previous rule set and it would get green images! */
list-style-type: disc;
list-style-image: url(pallo-punainen.gif); /* punainen = red */
list-style-position: inside;
margin-left: -10px;}

To CSS1 level matching patters can add the class-specifier. In fact a simple element type selector with a class is a matching pattern, because it does have two conditions (element type and class). But these kinds of simple combinations can also add to normal element type selectors creating more complex matching patterns like these ([M][S] - there is also models to the previous examples):

ul.class li {
list-style-type: disc;
list-style-image: url(pallo-vihrea.gif);
list-style-position: inside;
margin-left: -10px;}

table.special td p {color:green;}
/* according to this rule paragraphs inside tables, got green color only, if they are in a table, which have the class special. Note! You don't need to define the class, because in this case the browser doesn't search properties to any table elements but only to paragraphs, which are inside the table! */

Let's looks at also CSS2 level matching patterns, because it is desirable, that browsers would support them. Following scheme describe this matter (OL and UL are list types; LI means individual list-items; I have tried to explain the system with some comments - think it in peace):

1) ul li ol li /* match to class="a"; this is a CSS1 level matching pattern and I recommend for some time to use only this kind of patterns */
2) ul li ol > li /* match to class="b" */
3) ul li ol > li:first-child /* match to class="b+" */
4) ul li ol + ul /* match to class="c" */
<LI class="b+"></LI>
/* class="b+" is the first child-element of the element OL (first-child selector together with the :first-child pseudo-class): any property for this element doesn't concern neither next level list elements nor other list items at the same level */
<LI and class="b"></LI> /* class="b" is the second child-element of the element OL (first-child selector): any properties for this level child-elements don't concern next level list elements */
<LI class="a"></LI>
/* class="a"; this element gets its properties according to the first rule, even if it is not the first-level child of element OL but second level "grand-child"; If this element have child-elements, they would get their properties from this element */
<UL class="c"> /* in this case element UL is at the same level being adjacent sibling of OL, which define properties also to the following list-elements */

It is also remarkable to remember that the length of the pattern is not the only meaningful factor. When I designed the list test, which I have mentioned, I made an error. I had not found all mutual relationships of different rules. I try to sketch them to you by this example:

li ol+ul {list-style-type: disc; /* according this rule the list-image should be red; It tested it with a preview-version of Netscape 6.x */
list-style-image: url(./Css/Kuvat/pallo-punainen.gif);
list-style-position: outside;}

ul li {list-style-type: disc; /* the previous rule don't remain in use, because the shorter pattern UL LI cancels it and redefine list-elements; It just continues at the point, where the latter definitions ends! */
list-style-image: url(./Css/Kuvat/pallo.gif);
list-style-position: outside;}

li ol+ul li {list-style-type: disc; /* in order to get the second rule in use, it must continue with an additional element LI - now Netscape shows the desired image! */
list-style-image: url(./Css/Kuvat/pallo-punainen.gif);
list-style-position: outside;}

The most exact matching pattern could be created by combining element and attribute What are selectors, classes and id-attributes[S][Pw].

Browser-specific notes:

  1. MS IE browsers don't support any new CSS2-level patterns.

  2. Only Mozilla Gecko and Opera 7.x browsers support all kinds of in this page mentioned pattern including the :first-child pseudo-class and attribute selectors (you can look a model list[S][Pw] from the error page, how selectors should work).

  3. Opera 3.6x doesn't support rules like .class p {...}..

  4. Opera 3.6x+ support rules like OL > LI {...}.

  5. Opera 5.x-6.x browser support also partially or fully rules like OL + UL {...}.

  6. Opera 4.x+ browser support attribute selectors.


Cascading order


Ordinary situations

Matching criterion are in principle simple. They include the cascading order. The browser might find definition, which have the same weight. Rules, which have the same weight last given remain in use.

In matching properties the main principle is that more specific override more common and last given all previous given rules. In this process it is also necessary to remember the usage of the import rule at-rule (@import), which I have already handled in the page How to put CSS into Web pages[S][Pw].

Cascading order is a part of the What is the processing order of CSS. In my mind it could be also written about cascading What is the processing order of CSS. Cascading order is connected to the pattern matching. The whole system can be simplified into tree main factors:

  • Inheritance (in CSS1 level only as automatic system + in CSS2 level also "forced inheritance")
  • All kinds of selectors with another selectors are matching patterns
  • Cascading order

Because these three factors are whole time in work, it is impossible to present a common model, which could describe, which definition is more specific than other. It is only possible to give some practical examples or general guidelines. The author must think in his mind, how browsers make their decisions in individual cases. He must know, what browsers can fulfil and what can't! Remember always also the document tree. Following order gives some general advice, when the effort is from general towards specific. The order might be in individual cases different.

  1. Bare universal selector
  2. BODY element without a class selector
  3. Class-specified universal selector
  4. Other Individual element type selector as BODY
  5. Other Individual element type selector as BODY with class selector
  6. Complex matching pattern, which have also class What are selectors, classes and id-attributes
  7. Id selector

Authors certainly want to create as manageable and powerful system as possible and where is minimum need of individual style definitions inside the document body. I give following recommendations:

  1. Single common BODY element definition with some common table declarations (I explain the latter in the page How to set CSS for table elements[S][Pw].
  2. Concerning document orientated definitions several rules to BODY element with different class and id specifiers
  3. Individual font styles have their own rules
  4. All other rules are made using matching patterns, which are counted from class specified BODY elements
  5. All kinds of specific document oriented definitions are used with care

Important rule

The normal cascading order can override by using so-called !important rule like:

body { color: black !important; background: white !important;}

If the order doesn't meet any other important rules, any afterward given corresponding properties are not taken account. The rule concern primary the cascading order overriding the normal order. But the rule concerns not only the cascading order. Properties, which are given with the import rule override also class, id selector, matching patterns and style attributes to the same element.

The !important rule concerns however only certain element and properties, which are given to the element. If some child-element has its own declaration, it remains in use. The following tested examples explain this complex matter ([M][S][Pw]):

body {color: black !important;}
body.CssSite {color:blue;}
/* the !important rule override this color-definition even if the BODY has as a specifier class CssSite */
p.new {color:blue;} /* the first definition is canceled, because to the BODY element given important rule doesn't override the property of the anew defined child-element (in this case it doesn't matter, if the child element have class specifier or not) but this rule is now in use; If the element P has not its own color-property, it inherit it from the BODY, which have the !important rule */
p {color:olive !important}
/* all previous definitions are canceled concerning the element P; Now it is in use a new important rule, which concerns the element P */
p#id-p {color:blue;} /* the previous important rule override also this definition and following definition, which is in the document body inside an element P; Because it is stronger than id selector, it is also stronger than matching patterns */

<BODY> <P style ="color:purple;">
You might believe, that the color of this paragraph would be purple, but it not true. The color is instead olive according to the important rule! Is this the result, what you really mean?
<P style ="color:purple !important;">If you want, that this definition could be in use, you must put the important rule to it!</p>

Because of the important rule overrides all other rules to an element, it is a certain kind of exception rule (the term is however quite problematic; read the Footnote 1). Authors might override with the important rule definitions, which they really don't want to override! Because the rule might cause much headaches to the authors and extra work to browsers, I recommend to use it extremely cautious.

Browser-specific notes:.

  1. Important rule doesn't work in Netscape 4.x series.

  2. With pseudo-elements :first-letter ja :first-line the important rule is related with only the element itself. If the element immediately starts with another element (for example >p>>cite>) different property values for child elements stay in Opera 7.x (for example cite {font-weight:normal} even if p:first-letter {font-weight:bold !important}). With other moder browser it is possible to override properties of the child-element with the !important rule. In my mind Opera 7.x works fully consitent.

  3. Redefining of the important rule doesn't always work.

After handling basics of CSS I handle next closer fonts and how to tailor web sites to different people and medias.


Footnote 1. The problem is, that it is not a rule in that way as in most cases is called a rule (look at the page What are selectors, classes and id-attributes[S][Pw]). But it is neither a declaration-block (look at the definition of declaration-block from the page Definition methods[S][Pw]. Because it is inside a single declaration, it might be called as the important declaration. The another correct alternative is to call the important rule as important properties, because they are added to the normal property list among normal properties like in this declaration-block: {color:blue !important; background-color: green}. !important creates however exceptional declarations, which weight are related to normal rules. Selectors + important rules create together conditional sequences or statements, which we can call as rules.