Contents
In this section, we begin the formal specification of CSS2, starting with the contract between authors, documents, users, and user agents.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. However, for readability, these words do not appear in all upper case letters in this specification.
At times, the authors of this specification recommend good practice for authors and user agents. These recommendations are not normative and conformance with this specification does not depend on their realization. These recommendations contain the expression "We recommend ...", "This specification recommends ...", or some similar wording.
Style sheets may have three different origins: author, user, and user agent. The interaction of these sources is described in the section on cascading and inheritance.
All valid level N-1 style sheets are valid level N style sheets. In particular, all valid CSS1 style sheets are valid CSS2 style sheets.
A valid CSS2 style sheet must respect the grammar of CSS2 and the selector syntax. Furthermore, it must only contain at-rules, property names, and property values defined in this specification.
The primary syntactic constructs of the document language are called elements, (an SGML term, see [ISO8879]). Most CSS style sheet rules refer to these elements and specify rendering information for them. Examples of elements in HTML include "P" (for structuring paragraphs), "TABLE" (for creating tables), "OL" (for creating ordered lists), etc.
The content of an element is the content of that element in the source document; not all elements have content. The rendered content of an element is the content actually rendered. An element's content is generally its rendered content. The rendered content of a replaced element comes from outside the source document. Rendered content may also be alternate text for an element (e.g., the value of the HTML "alt" attribute).
An element A is called an ancestor of an element B, if either (1) A is the parent B, or (2) A is the parent of some element C that is an ancestor of B.
An element A is called a descendant of an element B, if and only if B is an ancestor of A. An element A is called a child of an element B, if and only if B is the parent of A.
An element A is called a sibling of an element B, if and only if B and A share the same parent element. Element A is a preceding sibling if it comes before B in the document tree. Element B is a following sibling if it comes after B in the document tree.
An element A is called a preceding element of an element B, if and only if (1) A is an ancestor of B or (2) A is a preceding sibling of B. An element A is called a following element of an element B, if and only if (1) A is an descendant of B or (2) A is a following sibling of B.
For example, the following HTML document:
<HTML> <TITLE>My home page</TITLE> <BODY> <H1>My home page</H1> <P>Welcome to my home page! Let me tell you about my favorite composers: <UL> <LI> Elvis Costello <LI> Johannes Brahms <LI> Georges Brassens </UL> </BODY> </HTML>
results in the following tree:
According to the definition of HTML, HEAD elements will be inferred during parsing and become part of the document tree even if the HEAD tags are not in the document source.
This section defines conformance with the CSS2 specification only. There may be other levels of CSS in the future that may require a user agent to implement a different set of features in order to conform.
In general, the following points must be observed by user agents claiming conformance to this specification:
Not every user agent must observe every point, however:
The inability of a user agent to implement part of this specification due to the limitations of a particular device (e.g., a user agent cannot render colors on a monochrome monitor or page) does not imply non-conformance.
This specification also recommends that a user agent offer the following functionality to the user (these do not refer to any specific user interface):
In general, this document does not specify error handling behavior for user agents.
However, user agents must observe the rules for handling parsing errors.
Since user agents may vary in how they handle error conditions, authors and users must not rely on specific error recovery behavior.