CSS Values and Units Module Level 4

1. Introduction

The value definition field of each CSS property can contain keywords, data types (which appear between < and >), and information on how they can be combined. Generic data types (<length> being the most widely used) that can be used by many properties are described in this specification, while more specific data types (e.g., <spacing-limit>) are described in the corresponding modules.

1.1. Module Interactions

This module replaces and extends the data type definitions in [CSS2] sections 1.4.2.1, 4.3, and A.2.

2. Value Definition Syntax

The value definition syntax described here is used to define the set of valid values for CSS properties (and the valid syntax of many other parts of CSS). A value so described can have one or more components.

2.1. Component Value Types

Component value types are designated in several ways:

Keyword values (such as auto, disc, etc.) and at-keywords representing the start of an at-rule, which appear literally, without quotes (e.g. auto or @media).

Note: It is possible, with escaping, to construct a CSS identifier whose value ends with ( or starts with @. Such a token is an <ident-token> (i.e. a keyword), not a <function-token> or an <at-keyword-token>.
Basic data types, which appear between < and > (e.g., <length>, <percentage>, etc.). For numeric data types, this type notation can annotate any range restrictions using the bracketed range notation described below.
Property value ranges, which represent the same pattern of values as a property bearing the same name. These are written as the property name, surrounded by single quotes, between < and >, e.g., <'border-width'>, <'background-attachment'>, etc.

These types do not include CSS-wide keywords such as inherit. Additionally, if the property’s value grammar is a comma-separated repetition, the corresponding type does not include the top-level comma-separated list multiplier. (E.g. if a property named pairing is defined as [ <custom-ident> <integer>? ]#, then <'pairing'> is equivalent to [ <custom-ident> <integer>? ], not [ <custom-ident> <integer>? ]#.)

Why remove the multiplier?

The top-level multiplier is ripped out of these value types because top-level comma-separated repetitions are mostly used for coordinating list properties, and when a shorthand combines several such properties, it needs the unmultiplied grammar so it can construct its own comma-separated repetition.

Without this special treatment, every such longhand would have to be defined with an ad-hoc production just for the inner value, which makes the grammars harder to understand overall.
Functional notations and their arguments. These may be written literally as defined in § 2.6 Functional Notation Definitions, or referenced by a non-terminal using the function’s name, followed by an empty parentheses pair, between < and >, e.g. <calc()>, and references the correspondingly-named functional notation.
Other non-terminals. These are written as the name of the non-terminal between < and >, as in <spacing-limit>. Notice the distinction between <border-width> and <'border-width'>: the latter represents the grammar of the border-width property, the former requires an explicit expansion elsewhere. The definition of a non-terminal is typically located near its first appearance in the specification.
Delimiters, which represent their corresponding tokens. Slashes (/), commas (,), colons (:), semicolons (;), parentheses (( and )), and braces ({ and }) are written literally. Other delimiters must be written enclosed in single quotes (such as '+').

Commas specified in the grammar are implicitly omissible in some circumstances, when used to separate optional terms in the grammar. Within a top-level list in a property or other CSS value, or a function’s argument list, a comma specified in the grammar must be omitted if:

all items preceding the comma have been omitted
all items following the comma have been omitted
multiple commas would be adjacent (ignoring white space/comments), due to the items between the commas being omitted.

For example, if a function can accept three arguments in order, but all of them are optional, the grammar can be written like:

example( first? , second? , third? )

Given this grammar, writing example(first, second, third) is valid, as is example(first, second) or example(first, third) or example(second). However, example(first, , third) is invalid, as one of those commas are no longer separating two options; similarly, example(,second) and example(first,) are invalid. example(first second) is also invalid, as commas are still required to actually separate the options.

If commas were not implicitly omittable, the grammar would have to be much more complicated to properly express the ways that the arguments can be omitted, greatly obscuring the simplicity of the feature.

All CSS properties also accept the CSS-wide keyword values as the sole component of their property value. For readability these are not listed explicitly in the property value syntax definitions. For example, the full value definition of border-color under CSS Cascading and Inheritance Level 3 is <color>{1,4} | inherit | initial | unset (even though it is listed as <color>{1,4}).

Note: This implies that, in general, combining these keywords with other component values in the same declaration results in an invalid declaration. For example, background: url(corner.png) no-repeat, inherit; is invalid.

2.2. Component Value Combinators

Component values can be arranged into property values as follows:

Juxtaposing components means that all of them must occur, in the given order.
A double ampersand (&&) separates two or more components, all of which must occur, in any order.
A double bar (||) separates two or more options: one or more of them must occur, in any order.
A bar (|) separates two or more alternatives: exactly one of them must occur.
Brackets ([ ]) are for grouping.

Juxtaposition is stronger than the double ampersand, the double ampersand is stronger than the double bar, and the double bar is stronger than the bar. Thus, the following lines are equivalent:

  a b   |   c ||   d &&   e f
[ a b ] | [ c || [ d && [ e f ]]]

For reorderable combinators (||, &&), ordering of the grammar does not matter: components in the same grouping may be interleaved in any order. Thus, the following lines are equivalent:

a || b || c
b || a || c

Note: Combinators are not associative, so grouping is significant. For example, a || b || c and a || [ b || c ] are distinct grammars: the first allows a value like b a c, but the second does not.

2.3. Component Value Multipliers

Every type, keyword, or bracketed group may be followed by one of the following modifiers:

An asterisk (*) indicates that the preceding type, word, or group occurs zero or more times.
A plus (+) indicates that the preceding type, word, or group occurs one or more times.
A question mark (?) indicates that the preceding type, word, or group is optional (occurs zero or one times).
A single number in curly braces ({A}) indicates that the preceding type, word, or group occurs A times.
A comma-separated pair of numbers in curly braces ({A,B}) indicates that the preceding type, word, or group occurs at least A and at most B times. The B may be omitted ({A,}) to indicate that there must be at least A repetitions, with no upper bound on the number of repetitions.
A hash mark (#) indicates that the preceding type, word, or group occurs one or more times, separated by comma tokens (which may optionally be surrounded by white space and/or comments). It may optionally be followed by the curly brace forms, above, to indicate precisely how many times the repetition occurs, like <length>#{1,4}.
An exclamation point (!) after a group indicates that the group is required and must produce at least one value; even if the grammar of the items within the group would otherwise allow the entire contents to be omitted, at least one component value must not be omitted.

The + and # multipliers may be stacked as +#; similarly, the # and ? multipliers, {A} and ? multipliers, and {A,B} and ? multipliers may be stacked as #?, {A}?, and {A,B}?, respectively. These stacks each represent the later multiplier applied to the result of the earlier multiplier. (These same stacks can be represented using grouping, but in complex grammars this can push the number of brackets beyond readability.)

For repeated component values (indicated by *, +, or #), UAs must support at least 20 repetitions of the component. If a property value contains more than the supported number of repetitions, the declaration must be ignored as if it were invalid.

2.4. Combinator and Multiplier Patterns

There are a small set of common ways to combine multiple independent component values in particular numbers and orders. In particular, it’s common to want to express that, from a set of component value, the author must select zero or more, one or more, or all of them, and in either the order specified in the grammar or in any order.

All of these can be easily expressed using simple patterns of combinators and multipliers:

	in order	any order
zero or more	`A? B? C?`	`A? \|\| B? \|\| C?`
one or more	`[ A? B? C? ]!`	`A \|\| B \|\| C`
all	`A B C`	`A && B && C`

Note that all of the "any order" possibilities are expressed using combinators, while the "in order" possibilities are all variants on juxtaposition.

2.5. Component Values and White Space

Unless otherwise specified, white space and/or comments may appear before, after, and/or between components combined using the above combinators and multipliers.

Note: In many cases, spaces will in fact be required between components in order to distinguish them from each other. For example, the value 1em2em would be parsed as a single <dimension-token> with the number 1 and the identifier em2em, which is an invalid unit. In this case, a space would be required before the 2 to get this parsed as the two lengths 1em and 2em.

2.6. Functional Notation Definitions

The syntax of a functional notation is defined as a sequence of:

The function’s name written as an identifier followed by an open parenthesis (such as example(), or the <function-token> production to indicate a function with an arbitrary name.
The function’s arguments, if any, expressed using the value definition syntax.
A literal closing parenthesis.

The function’s arguments are considered implicitly grouped, as if surrounded by brackets ([ ... ]).

For example, a grammar like:

example( <length> , <length> )

will match a function whose name is "example" and whose arguments match "<length> , <length>".

For example, the Selectors grammar defines pseudo-classes generically, allowing any possibly function name after the initial colon:

<pseudo-class-selector> = : <ident-token> | : <function-token> <any-value> )

This represents any function name, with <any-value> as the function arguments.

Since the functional notation implicitly groups its contents, the effect of any combinator inside it is scoped to the function’s argument. For example, the functional notation syntax definition example( foo | bar ) is equivalent to example( [ foo | bar ] ).

2.7. Property Value Examples

Below are some examples of properties with their corresponding value definition fields

Property	Value definition field	Example value
orphans	<integer>	3
text-align	left \| right \| center \| justify	center
padding-top	<length> \| <percentage>	5%
outline-color	<color> \| invert	#fefefe
text-decoration	none \| underline \|\| overline \|\| line-through \|\| blink	overline underline
font-family	[ <family-name> \| <generic-family> ]#	"Gill Sans", Futura, sans-serif
border-width	[ <length> \| thick \| medium \| thin ]{1,4}	2px medium 4px
box-shadow	[ inset? && <length>{2,4} && <color>? ]# \| none	3px 3px rgba(50%, 50%, 50%, 50%), lemonchiffon 0 0 4px inset

2.8. Non-Terminal Definitions and Grammar Production Blocks

The precise grammar of non-terminals, like <position> or <calc()>, is often specified in a CSS grammar production block. These are conventionally represented in a preformatted block of definitions like this:

The <foo> syntax is defined as follows:

<foo> = keyword | <bar> |
        some-really-long-pattern-of-stuff
<bar> = <length>

Each definition starts on its own line, and consists of the non-terminal to be defined, followed by an =, followed by the fragment of value definition syntax to which it expands. A definition can stretch across multiple lines, and terminates before the next line that starts a new grammar production or at the end of the grammar production block (whichever comes first).

In the above example, the <foo> definition covers two lines. The third line starts a new definition for <bar>. (A naked = is never valid in value definition syntax, so it’s unambiguous when a new line starts a fresh definition.)

3. Combining Values: Interpolation, Addition, and Accumulation

Some procedures, for example transitions and animations, combine two CSS property values. The following combining operations—on the two computed values V_A and V_B yielding the computed value V_result—are defined. For operations that are not commutative (for example, matrix multiplication, or accumulation of mismatched transform lists) V_A represents the first term of the operation and V_B represents the second.

interpolation

Given two property values V_A and V_B, produces an intermediate value V_result at a distance of p along the interval between V_A and V_B such that p = 0 produces V_A and p = 1 produces V_B.

The range of p is (−∞, ∞) due to the effect of timing functions. As a result, this procedure must also define extrapolation behavior for p outside [0, 1].

addition

Given two property values V_A and V_B, returns the sum of the two properties, V_result.

Note: While addition can often be expressed in terms of the same weighted sum function used to define interpolation, this is not always the case. For example, interpolation of transform matrices involves decomposing and interpolating the matrix components whilst addition relies on matrix multiplication.

If a value type does not define a specific procedure for addition or is defined as not additive, its addition operation is simply V_result = V_B.

accumulation

Given two property values V_A and V_B, returns the result, V_result, of combining the two operands such that V_B is treated as a delta from V_A.

Note: For many types of animation such as numbers or lengths, accumulation is defined to be identical to addition.

A common case where the definitions differ is for list-based types where addition may be defined as appending to a list whilst accumulation may be defined as component-based addition. For example, the filter list values blur(2) and blur(3), when added together would produce blur(2) blur(3), but when accumulated would produce blur(5).

If a value type does not define a specific procedure for accumulation, its accumulation operation is identical to addition.

These operations are only defined on computed values. (As a result, it is not necessary to define, for example, how to add a <length> value of 15pt with 5em since such values will be resolved to their canonical unit before being passed to any of the above procedures.)

3.1. Range Checking

Interpolation can result in a value outside the valid range for a property, even if all of the inputs to interpolation are valid; this especially happens when p is outside the [0, 1] range, but some easing functions can cause this to occur even within that range. If the final result after interpolation, addition, and accumulation is out-of-range for the target context the value is being used in, it does not cause the declaration to be invalid. Instead, the value must be clamped to the range allowed in the target context, exactly the same as math functions (see § 10.12 Range Checking).

Note: Even if interpolation results in an out-of-range value, addition/accumulation might "correct" the result and bring it back into range. Thus, clamping is only applied to the final result of applying all interpolation-related operations.

4. Textual Data Types

The textual data types include various keywords and identifiers as well as strings (<string>) and URLs (<url>). Aside from the casing of pre-defined keywords or as explicitly defined for a given property, no normalization is performed, not even Unicode normalization: the specified and computed value of a property are exactly the provided Unicode values after parsing (which includes character set conversion and escaping). [UNICODE] [CSS-SYNTAX-3]

CSS identifiers, generically denoted by <ident>, consist of a sequence of characters conforming to the <ident-token> grammar. [CSS-SYNTAX-3] Identifiers cannot be quoted; otherwise they would be interpreted as strings. CSS properties accept two classes of identifiers: pre-defined keywords and author-defined identifiers.

Note: The <ident> production is not meant for property value definitions—<custom-ident> should be used instead. It is provided as a convenience for defining other syntactic constructs.

All textual data types interpolate as discrete and are not additive.

4.1. Pre-defined Keywords

In the value definition fields, keywords with a pre-defined meaning appear literally. Keywords are identifiers and are interpreted ASCII case-insensitively (i.e., [a-z] and [A-Z] are equivalent).

For example, here is the value definition for the border-collapse property:

Value: collapse | separate

And here is an example of its use:

table { border-collapse: separate }

4.1.1. CSS-wide keywords: initial, inherit and unset

As defined above, all properties accept the CSS-wide keywords, which represent value computations common to all CSS properties. These keywords are normatively defined in the CSS Cascading and Inheritance Module.

Tests

Other CSS specifications can define additional CSS-wide keywords.

4.2. Unprefixed Author-defined Identifiers: the <custom-ident> type

Some properties accept arbitrary author-defined identifiers as a component value. This generic data type is denoted by <custom-ident>, and represents any valid CSS identifier that would not be misinterpreted as a pre-defined keyword in that property’s value definition. Such identifiers are fully case-sensitive (meaning they’re compared using the "identical to" operation), even in the ASCII range (e.g. example and EXAMPLE are two different, unrelated user-defined identifiers).

The CSS-wide keywords are not valid <custom-ident>s. The default keyword is reserved and is also not a valid <custom-ident>. Specifications using <custom-ident> must specify clearly what other keywords are excluded from <custom-ident>, if any—for example by saying that any pre-defined keywords in that property’s value definition are excluded. Excluded keywords are excluded in all ASCII case permutations.

When parsing positionally-ambiguous keywords in a property value, a <custom-ident> production can only claim the keyword if no other unfulfilled production can claim it.

For example, the shorthand declaration animation: ease-in ease-out is equivalent to the longhand declarations animation-timing-function: ease-in; animation-name: ease-out;. ease-in is claimed by the <easing-function> production belonging to animation-timing-function, leaving ease-out to be claimed by the <custom-ident> production belonging to animation-name.

Note: When designing grammars with <custom-ident>, the <custom-ident> should always be “positionally unambiguous”, so that it’s impossible to conflict with any keyword values in the property. Such conflicts can alternatively be avoided by using <dashed-ident>.

4.3. Prefixed Author-defined Identifiers: the <dashed-ident> type

Some contexts accept both author-defined identifiers and CSS-defined identifiers. If not handled carefully, this can result in difficulties adding new CSS-defined values; UAs have to study existing usage and gamble that there are sufficiently few author-defined identifiers in use matching the new CSS-defined one, so giving the new value a special CSS-defined meaning won’t break existing pages.

While there are many legacy cases in CSS that mix these two values spaces in exactly this fraught way, the <dashed-ident> type is meant to be an easy way to distinguish author-defined identifiers from CSS-defined identifiers.

The <dashed-ident> production is a <custom-ident>, with all the case-sensitivity that implies, with the additional restriction that it must start with two dashes (U+002D HYPHEN-MINUS).

<dashed-ident>s are reserved solely for use as author-defined names. CSS will never define a <dashed-ident> for its own use.

For example, custom properties need to be distinguishable from CSS-defined properties, as new properties are added to CSS regularly. To allow this, custom property names are required to be <dashed-ident>s, as in this example:

.foo {
  --fg-color: blue;
}

<dashed-ident>s are also used in the @color-profile rule, to separate author-defined color profiles from pre-defined ones like device-cmyk, and allow CSS to define more pre-defined (but overridable) profiles in the future without fear of clashing with author-defined profiles:

@color-profile --foo { src: url(https://example.com/foo.icc); }
.foo {
  color: color(--foo 1 0 .5 / .2);
}

CSS will use <dashed-ident> more in the future, as more author-controlled syntax is added. CSS authoring tools, such as preprocessors that turn custom syntax into standard CSS, should use <dashed-ident> as well, to avoid clashing with future CSS design.

For example, if a CSS preprocessor added a new "custom" at-rule, it shouldn’t spell it @custom, as this would clash with a future official @custom rule added by CSS. Instead, it should use @--custom, which is guaranteed to never clash with anything defined by CSS.

Even better, it should use @--library1-custom, so that if Library2 adds their own "custom" at-rule (spelled @--library2-custom), there’s no possibility of clash. Ideally this prefix should be customizable, if allowed by the tooling, so authors can manually avoid clashes on their own.

4.4. Quoted Strings: the <string> type

Strings are denoted by <string>. When written literally, they consist of a sequence of characters delimited by double quotes or single quotes, corresponding to the <string-token> production in the CSS Syntax Module [CSS-SYNTAX-3].

Double quotes cannot occur inside double quotes, unless escaped (as "\"" or as "\22"). Analogously for single quotes ('\'' or '\27').

content: "this is a 'string'.";
content: "this is a \"string\".";
content: 'this is a "string".';
content: 'this is a \'string\'.'

It is possible to break strings over several lines, for aesthetic or other reasons, but in such a case the newline itself has to be escaped with a backslash (\). The newline is subsequently removed from the string. For instance, the following two selectors are exactly the same:

a[title="a not s\
o very long title"] {/*...*/}
a[title="a not so very long title"] {/*...*/}

Since a string cannot directly represent a newline, to include a newline in a string, use the escape "\A". (Hexadecimal A is the line feed character in Unicode (U+000A), but represents the generic notion of "newline" in CSS.)

4.5. Resource Locators: the <url> type

The <url> type, written with the url() and src() functions, represents a URL, which is a pointer to a resource.

The syntax of <url> is:

<url> = <url()> | <src()>

<url()> = url( <string> <url-modifier>* ) | <url-token>
<src()> = src( <string> <url-modifier>* )

This example shows a URL being used as a background image:

body { background: url("http://www.example.com/pinkish.gif") }

A url() can be written without quotation marks around the URL value, in which case it is specially-parsed as a <url-token>; see CSS Syntax 3 § 4.3.6 Consume a url token. [CSS-SYNTAX-3]

Note: Because of this special parsing, url() can only express its value literally. To provide a URL by functions such as var(), use the src() notation, which does not have this special parsing rule.

For example, the following declarations are identical:

background: url("http://www.example.com/pinkish.gif");
background: url(http://www.example.com/pinkish.gif);

And these have the same meaning as well:

background: src("http://www.example.com/pinkish.gif");
--foo: "http://www.example.com/pinkish.gif";
background: src(var(--foo));

But this does not work:

--foo: "http://www.example.com/pinkish.gif";
background: url(var(--foo));

...because the unescaped "(" in the value causes a parse error, so the entire declaration is thrown out as invalid.

Note: The unquoted url() syntax cannot accept a <url-modifier> argument and has extra escaping requirements: parentheses, whitespace characters, single quotes (') and double quotes (") appearing in a URL must be escaped with a backslash, e.g. url(open\(parens), url(close\)parens). (In quoted <string> url()s, only newlines and the character used to quote the string need to be escaped.) Depending on the type of URL, it might also be possible to write these characters as URL-escapes (e.g. url(open%28parens) or url(close%29parens)) as described in