CSS Values and Units Module Level 4

Editor’s Draft,

More details about this document
This version:
https://drafts.csswg.org/css-values-4/
Latest published version:
https://www.w3.org/TR/css-values-4/
Feedback:
CSSWG Issues Repository
Inline In Spec
Editors:
Tab Atkins (Google)
Elika J. Etemad / fantasai (Apple)
Suggest an Edit for this Spec:
GitHub Editor
Test Suite:
https://wpt.fyi/results/css/css-values/

Abstract

This CSS module describes the common values and units that CSS properties accept and the syntax used for describing them in CSS property definitions.

CSS is a language for describing the rendering of structured documents (such as HTML and XML) on screen, on paper, etc.

Status of this document

This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.

Please send feedback by filing issues in GitHub (preferred), including the spec code “css-values” in the title, like this: “[css-values] …summary of comment…”. All issues and comments are archived. Alternately, feedback can be sent to the (archived) public mailing list [email protected].

This document is governed by the 18 August 2025 W3C Process Document.

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:

  1. 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>.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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:

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:

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:

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:

  1. 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.

  2. The function’s arguments, if any, expressed using the value definition syntax.

  3. 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 VA and VB yielding the computed value Vresult—​are defined. For operations that are not commutative (for example, matrix multiplication, or accumulation of mismatched transform lists) VA represents the first term of the operation and VB represents the second.

interpolation
Given two property values VA and VB, produces an intermediate value Vresult at a distance of p along the interval between VA and VB such that p = 0 produces VA and p = 1 produces VB.

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 VA and VB, returns the sum of the two properties, Vresult.

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 Vresult = VB.

accumulation
Given two property values VA and VB, returns the result, Vresult, of combining the two operands such that VB is treated as a delta from VA.
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:

Example(s):

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 [URL].

Some CSS contexts (such as @import) also allow a <url> to be represented by a bare <string>, without the function wrapper. In such cases the string behaves identically to a url() function containing that string.

For example, the following statements act identically:
@import url("base-theme.css");
@import "base-theme.css";

4.5.1. Relative URLs

In order to create modular style sheets that are not dependent on the absolute location of a resource, authors should use relative URLs. Relative URLs (as defined in [URL]) are resolved to full URLs using a base URL. RFC 3986, section 3, defines the normative algorithm for this process. For CSS style sheets, the base URL is that of the style sheet itself, not that of the styled source document. Style sheets embedded within a document have the base URL associated with their container.

Note: For HTML documents, the base URL is mutable.

When a <url> appears in the computed value of a property, it is resolved to an absolute URL. The computed value of a URL that the UA cannot resolve to an absolute URL is the specified value.

For example, suppose the following rule:
body { background: url("tile.png") }

is located in a style sheet designated by the URL:

http://www.example.org/style/basic.css

The background of the source document’s <body> will be tiled with whatever image is described by the resource designated by the URL:

http://www.example.org/style/tile.png

The same image will be used regardless of the URL of the source document containing the <body>.

4.5.1.1. Fragment URLs

To enable element ID references to work in CSS regardless of base URL changes or shadow DOM, <url>s have special behavior when they contain only a fragment.

If a <url>’s value starts with a U+0023 NUMBER SIGN (#) character, then the URL additionally has its local url flag set, and is a tree-scoped reference for the URL’s fragment.

When matching a <url> with the local url flag set:

Possibly reference find a potential indicated element, but that is defined specifically for Documents, not ShadowRoots.

Note: This means that such fragments will resolve against the contents of the current document (or whichever node tree the stylesheet lives in, if shadow DOM is involved) regardless of how such relative URLs would resolve elsewhere (ignoring, for example, base elements changing the base URL, or relative URLs in linked stylesheets resolving against the stylesheet’s URL).

In the following example, #anchor will resolve against http://example.com/ whereas #image will resolve against the elements in the HTML document itself:
<!DOCTYPE html>
<base href="http://example.com/">
...
<a href="#anchor" style="background-image: url(#image)">link</a>

When serializing a url() with the local url flag set, it must serialize as just the fragment.

4.5.2. Empty URLs

If the value of the <url> is the empty string (like url("") or url()), the url must resolve to an invalid resource (similar to what the url about:invalid does).

Its computed value is url("") or src(""), whichever was specified, and it must serialize as such.

Tests

Note: This matches the behavior of empty urls for embedded resources elsewhere in the web platform, and avoids excess traffic re-requesting the stylesheet or host document due to editing mistakes leaving the url() value empty, which are almost certain to be invalid resources for whatever the url() shows up in. Linking on the web platform does allow empty urls, so if/when CSS gains some functionality to control hyperlinks, this restriction can be relaxed in those contexts.

4.5.3. URL Modifiers

<url>s support specifying additional <url-modifier>s, which change the meaning or the interpretation of the URL somehow. A <url-modifier> is either an <ident> or a functional notation.

This specification does not define any <url-modifier>s, but other specs may do so.

Note: A <url> that is either unquoted or not wrapped in url() notation cannot accept any <url-modifier>s.

4.5.4. URL Processing Model

To compute the style resource base URL for a CSS rule or a CSS declaration block cssRuleOrDeclaration:
  1. Let sheet be null.

  2. If cssRuleOrDeclaration is a CSS declaration block whose parent CSS rule is not null, set cssRuleOrDeclaration to cssRuleOrDeclaration’s parent CSS rule.

  3. If cssRuleOrDeclaration is a CSS rule, set sheet to cssRuleOrDeclaration’s parent style sheet.

  4. If sheet is not null:

    1. If sheet’s stylesheet base URL is not null, return sheet’s stylesheet base URL.

    2. If sheet’s location is not null, return sheet’s location.

  5. Return cssRuleOrDeclaration’s relevant settings object’s API base URL.

To resolve a style resource URL from a url or <url> urlValue, and a CSS rule or a CSS declaration block cssRuleOrDeclaration:
  1. Let base be the style resource base URL given cssRuleOrDeclaration.

  2. Return the result of the URL parser steps with urlValue’s url and base.

To fetch a style resource from a url or <url> urlValue, given an CSS rule or a css declaration block cssRuleOrDeclaration, a string destination matching a RequestDestination, a "no-cors" or "cors" corsMode, and an algorithm processResponse accepting a response and a null, failure or byte stream:
  1. Let parsedUrl be the result of resolving urlValue given cssRuleOrDeclaration. If that failed, return.

  2. Let settingsObject be cssRuleOrDeclaration’s relevant settings object.

  3. Let req be a new request whose url is parsedUrl, whose destination is destination, mode is corsMode, origin is settingsObject’s origin, credentials mode is "same-origin", use-url-credentials flag is set, client is settingsObject, and whose referrer is "client".

  4. If corsMode is "no-cors", set req’s credentials mode to "include".

  5. Apply any URL request modifier steps that apply to this request.

    Note: This specification does not define any URL request modification steps, but other specs may do so.

  6. If req’s mode is "cors", and sheet is not null, then set req’s referrer to the style resource base URL given cssRuleOrDeclaration. [CSSOM]

  7. If sheet’s origin-clean flag is set, set req’s initiator type to "css". [CSSOM]

  8. Fetch req, with processResponseConsumeBody set to processResponse.

When interpreting URLs expressed in CSS, the URL parser’s encoding argument must be omitted (i.e. use the default, UTF-8), regardless of the stylesheet encoding.

Note: In other words, a URL written in CSS will always percent-encode non-ASCII codepoints using UTF-8 in the URL object (and thus whenever using the URL value for e.g. network requests), regardless of the stylesheet’s own encoding. Note that this occurs after decoding the stylesheet into Unicode code points.

5. Numeric Data Types

Numeric data types are used to represent quantities, indexes, positions, and other such values. Although many syntactic variations can exist in expressing the quantity (numeric aspect) in a given numeric value, the specified and computed value do not distinguish these variations: they represent the value’s abstract quantity, not its syntactic representation.

The numeric data types include <integer>, <number>, <percentage>, and various dimensions including <length>, <angle>, <time>, <frequency>, and <resolution>.

Note: While general-purpose dimensions are defined here, some other modules define additional data types (e.g. [css-grid-1] introduces fr units) whose usage is more localized.

The precision and supported range of numeric values in CSS is implementation-defined, and can vary based on the property or other context a value is used in. However, within the CSS specifications, infinite precision and range is assumed. When a value cannot be explicitly supported due to range/precision limitations, it must be converted to the closest value supported by the implementation, but how the implementation defines "closest" is implementation-defined as well.

If an <angle> must be converted due to exceeding the implementation-defined range of supported values, it must be clamped to the nearest supported multiple of 360deg.

5.1. Range Restrictions and Range Definition Notation

Properties can restrict numeric values to some range. If the value is outside the allowed range, then unless otherwise specified, the declaration is invalid and must be ignored. Range restrictions can be annotated in the numeric type notation using CSS bracketed range notation—​[min,max]—​within the angle brackets, after the identifying keyword, indicating a closed range between (and including) min and max. For example, <integer [0,10]> indicates an integer between 0 and 10, inclusive, while <angle [0,180deg]> indicates an angle between 0deg and 180deg (expressed in any unit).

Note: CSS values generally do not allow open ranges; thus only square-bracket notation is used.

CSS theoretically supports infinite precision and infinite ranges for all value types; however in reality implementations have finite capacity. UAs should support reasonably useful ranges and precisions. Range extremes that are ideally unlimited are indicated using ∞ or −∞ as appropriate. For example, <length [0,∞]> indicates a non-negative length.

If no range is indicated, either by using the bracketed range notation or in the property description, then [−∞,] is assumed.

Values of −∞ or ∞ must be written without units, even if the value type uses units. Values of 0 can be written without units, even if the value type doesn’t allow “unitless zeroes” (such as <time>).

Note: At the time of writing, the bracketed range notation is new; thus in most CSS specifications any range limitations are described only in prose. (For example, “Negative values are not allowed” or “Negative values are invalid” indicate a [0,] range.) This does not make them any less binding.

5.2. Integers: the <integer> type

Integer values are denoted by <integer>.

When written literally, an integer is one or more decimal digits 0 through 9 and corresponds to a subset of the <number-token> production in the CSS Syntax Module [CSS-SYNTAX-3]. The first digit of an integer may be immediately preceded by - or + to indicate the integer’s sign.

Tests

Unless otherwise specified, in the CSS specifications rounding to the nearest integer requires rounding in the direction of +∞ when the fractional portion is exactly 0.5. (For example, 1.5 rounds to 2, while -1.5 rounds to -1.)

5.2.1. Computation and Combination of <integer>

Unless otherwise specified, the computed value of a specified <integer> is the specified abstract integer.

Interpolation of <integer> is defined as Vresult = round((1 - p) × VA + p × VB); that is, interpolation happens in the real number space as for <number>s, and the result is converted to an <integer> by rounding to the nearest integer.

Addition of <integer> is defined as Vresult = VA + VB

Tests

5.3. Real Numbers: the <number> type

Number values are denoted by <number>, and represent real numbers, possibly with a fractional component.

Tests

When written literally, a number is either an integer, or zero or more decimal digits followed by a dot (.) followed by one or more decimal digits; optionally, it can be concluded by the letter “e” or “E” followed by an integer indicating the base-ten exponent in scientific notation. It corresponds to the <number-token> production in the CSS Syntax Module [CSS-SYNTAX-3]. As with integers, the first character of a number may be immediately preceded by - or + to indicate the number’s sign.

The value <zero> represents a literal number with the value 0. Expressions that merely evaluate to a <number> with the value 0 (for example, calc(0)) do not match <zero>; only literal <number-token>s do.

5.3.1. Computation and Combination of <number>

Unless otherwise specified, the computed value of a specified <number> is the specified abstract number.

Interpolation of <number> is defined as Vresult = (1 - p) × VA + p × VB

Addition of <number> is defined as Vresult = VA + VB

5.4. Numbers with Units: dimension values

The general term dimension refers to a number with a unit attached to it; and is denoted by <dimension>.

When written literally, a dimension is a number immediately followed by a unit identifier, which is an identifier. It corresponds to the <dimension-token> production in the CSS Syntax Module [CSS-SYNTAX-3]. Like keywords, unit identifiers are ASCII case-insensitive.

Tests

CSS uses <dimension>s to specify distances (<length>), durations (<time>), frequencies (<frequency>), resolutions (<resolution>), and other quantities.

5.4.1. Compatible Units

When serializing computed values [CSSOM], compatible units (those related by a static multiplicative factor, like the 96:1 factor between px and in, or the computed font-size factor between em and px) are converted into a single canonical unit. Each group of compatible units defines which among them is the canonical unit that will be used for serialization.

When serializing resolved values that are used values, all value types (percentages, numbers, keywords, etc.) that represent lengths are considered compatible with lengths. Likewise any future API that returns used values must consider any values that represent distances/durations/frequencies/etc. as compatible with the relevant class of dimensions, and canonicalize accordingly.

Tests

5.4.2. Combination of Dimensions

Interpolation of compatible dimensions (for example, two <length> values) is defined as Vresult = (1 - p) × VA + p × VB

Addition of compatible dimensions is defined as Vresult = VA + VB

5.5. Percentages: the <percentage> type

Percentage values are denoted by <percentage>, and indicates a value that is some fraction of another reference value.

When written literally, a percentage consists of a number immediately followed by a percent sign %. It corresponds to the <percentage-token> production in the CSS Syntax Module [CSS-SYNTAX-3].

Percentage values are always relative to another quantity, for example a length. Each property that allows percentages also defines the quantity to which the percentage refers. This quantity can be a value of another property for the same element, the value of a property for an ancestor element, a measurement of the formatting context (e.g., the width of a containing block), or something else.

Tests

5.5.1. Computation and Combination of <percentage>

Unless otherwise specified (such as in font-size, which computes its <percentage> values to <length>), the computed value of a percentage is the specified percentage.

Interpolation of <percentage> is defined as Vresult = (1 - p) × VA + p × VB

Addition of <percentage> is defined as Vresult = VA + VB

5.6. Mixing Percentages and Dimensions

In cases where a <percentage> can represent the same quantity as a dimension in the same component value position, and can therefore be combined with them in a calc() expression, the following convenience notations may be used in the property grammar:

<length-percentage>

Equivalent to [ <length> | <percentage> ], where the <percentage> will resolve to a <length>.

<frequency-percentage>

Equivalent to [ <frequency> | <percentage> ], where the <percentage> will resolve to a <frequency>.

<angle-percentage>

Equivalent to [ <angle> | <percentage> ], where the <percentage> will resolve to an <angle>.

<time-percentage>

Equivalent to [ <time> | <percentage> ], where the <percentage> will resolve to a <time>.

For example, the width property can accept a <length> or a <percentage>, both representing a measure of distance. This means that width: calc(500px + 50%); is allowed—​both values are converted to absolute lengths and added. If the containing block is 1000px wide, then width: 50%; is equivalent to width: 500px, and width: calc(50% + 500px) thus ends up equivalent to width: calc(500px + 500px) or width: 1000px.

On the other hand, the second and third arguments of the hsl() function can only be expressed as <percentage>s. Although calc() productions are allowed in their place, they can only combine percentages with themselves, as in calc(10% + 20%).

Note: Specifications should never alternate <percentage> in place of a dimension in a grammar unless they are compatible.

Note: More <type-percentage> productions can be added in the future as needed. A <number-percentage> will never be added, as <number> and <percentage> can’t be combined in calc().

5.6.1. Computation and Combination of Percentage and Dimension Mixes

The computed value of a percentage-dimension mix is defined as

Interpolation of percentage-dimension value combinations (e.g. <length-percentage>, <frequency-percentage>, <angle-percentage>, <time-percentage> or equivalent notations) is defined as

Addition of <percentage> is defined the same as interpolation except by adding each component rather than interpolating it.

5.7. Ratios: the <ratio> type

Ratio values are denoted by <ratio>, and represent the ratio of two numeric values. It most often represents an aspect ratio, relating a width (first) to a height (second).

When written literally, a ratio has the syntax:

<ratio> = <number [0,]> [ / <number [0,]> ]?

The second <number> is optional, defaulting to 1. However, <ratio> is always serialized with both components.

The computed value of a <ratio> is the pair of numbers provided.

If either number in the <ratio> is 0 or infinite, it represents a degenerate ratio (and, generally, won’t do anything).

If two <ratio>s need to be compared, divide the first number by the second, and compare the results. For example, 3/2 is less than 2/1, because it resolves to 1.5 while the second resolves to 2. (In other words, “tall” aspect ratios are less than “wide” aspect ratios.)

5.7.1. Combination of <ratio>

The interpolation of a <ratio> is defined by converting each <ratio> to a number by dividing the first value by the second (so a ratio of 3 / 2 would become 1.5), taking the logarithm of that result (so the 1.5 would become approximately 0.176), then interpolating those values. The result during the interpolation is converted back to a <ratio> by inverting the logarithm, then interpreting the result as a <ratio> with the result as the first value and 1 as the second value.

If either <ratio> is degenerate, the values cannot be interpolated.

For example, halfway through a linear interpolation from 5 / 1 to 3 / 2, the result is approximately the ratio 2.73 / 1 (roughly 11 / 4, slightly taller than a 3 / 1 ratio):
start  = log(5);   // ≈ 0.69897
end    = log(1.5); // ≈ 0.17609
interp = 0.69897*.5 + 0.17609*.5; // ≈ 0.43753
final  = 10^interp; // ≈ 2.73

Note: Interpolating over the logarithm of the ratio means the results are scale-independent (5 / 1 to 300 / 200 would give the same results as above), that they’re symmetrical over "wide" and "tall" variants (interpolating from 1 / 5 to 2 / 3 would give a ratio approximately equal to 1 / 2.73 at the halfway point), and that they’re symmetrical over whether the width is fixed and the height is based on the ratio or vice versa. These properties are not shared by many other possible interpolation strategies.

Note: Due to the properties of logarithms, any log can be used; the example here uses base-10 log, but if, say, the natural log and e was used, the intermediate results would be different but the final result would be the same.

Addition of <ratio>s is not possible.

6. Distance Units: the <length> type

Lengths refer to distance measurements and are denoted by <length> in the property definitions. A length is a dimension.

For zero lengths the unit identifier is optional (i.e. can be syntactically represented as the <number> 0). However, if a 0 could be parsed as either a <number> or a <length> in a property (such as line-height), it must parse as a <number>.

Properties may restrict the length value to some range. If the value is outside the allowed range, the declaration is invalid and must be ignored.

Tests

While some properties allow negative length values, this may complicate the formatting and there may be implementation-specific limits. If a negative length value is allowed but cannot be supported, it must be converted to the nearest value that can be supported.

In cases where the used length cannot be supported, user agents must approximate it in the actual value.

There are two types of length units: relative and absolute. The specified value of a length (specified length) is represented by its quantity and its unit. The computed value of a length (computed length) is the specified length resolved to an absolute length, and its unit is not distinguished: it can be represented by any absolute length unit (but will be serialized using its canonical unit, px).

Tests

While the exact supported precision of numeric values, and how they are rounded to match that precision, is generally implementation-defined, <length>s in border-width and a few other properties are rounded in a specific fashion to ensure reasonable visual display. (This algorithm is called by individual properties explicitly.)

To snap a length as a border width given a <length> len:
  1. Assert: len is non-negative.

  2. If len is an integer number of device pixels, do nothing.

  3. If len is greater than zero, but less than 1 device pixel, round len up to 1 device pixel.

  4. If len is greater than 1 device pixel, round it down to the nearest integer number of device pixels.

6.1. Relative Lengths

Relative length units specify a length relative to another length. Style sheets that use relative units can more easily scale from one output environment to another.

The relative units are:

Informative Summary of Relative Units
unit relative to
em font size of the element
ex x-height of the element’s font
cap cap height (the nominal height of capital letters) of the element’s font
ch typical character advance of a narrow glyph in the element’s font, as represented by the “0” (ZERO, U+0030) glyph
ic typical character advance of a fullwidth glyph in the element’s font, as represented by the “水” (CJK water ideograph, U+6C34) glyph
rem font size of the root element
lh line height of the element
rlh line height of the root element
vw 1% of viewport’s width
vh 1% of viewport’s height
vi 1% of viewport’s size in the root element’s inline axis
vb 1% of viewport’s size in the root element’s block axis
vmin 1% of viewport’s smaller dimension
vmax 1% of viewport’s larger dimension

Child elements do not inherit the relative values as specified for their parent; they inherit the computed values.

6.1.1. Font-relative Lengths: the em, rem, ex, rex, cap, rcap, ch, rch, ic, ric, lh, rlh units

The font-relative lengths refer to the font metrics either of the element on which they are used (for the local font-relative lengths) or of the root element (for the root font-relative lengths).

The word 'Sphinx' annotated with various font metrics: ascender height, to the top of the h's serif; cap height, to the visually approximate top of the S; the x height, to the visually approximate top of the x; the baseline, along the bottom of S, h, i, n, and x; and the descender height, to the bottom fo the p.
Common typographic metrics
em
Equal to the computed value of the font-size property of the element on which it is used.
The rule:
h1 { line-height: 1.2em }

means that the line height of h1 elements will be 20% greater than the font size of h1 element. On the other hand:

h1 { font-size: 1.2em }

means that the font size of h1 elements will be 20% greater than the computed font size inherited by h1 elements.

rem
Equal to the computed value of the em unit on the root element.
Tests
ex
Equal to the used x-height of the first available font [CSS3-FONTS]. The x-height is so called because it is often equal to the height of the lowercase "x". However, an ex is defined even for fonts that do not contain an "x". The x-height of a font can be found in different ways. Some fonts contain reliable metrics for the x-height. If reliable font metrics are not available, UAs may determine the x-height from the height of a lowercase glyph. One possible heuristic is to look at how far the glyph for the lowercase "o" extends below the baseline, and subtract that value from the top of its bounding box. In the cases where it is impossible or impractical to determine the x-height, a value of 0.5em must be assumed.
Tests
rex
Equal to the value of the ex unit on the root element.
cap
Equal to the used cap-height of the first available font [CSS3-FONTS]. The cap-height is so called because it is approximately equal to the height of a capital Latin letter. However, a cap is defined even for fonts that do not contain Latin letters. The cap-height of a font can be found in different ways. Some fonts contain reliable metrics for the cap-height. If reliable font metrics are not available, UAs may determine the cap-height from the height of an uppercase glyph. One possible heuristic is to look at how far the glyph for the uppercase “O” extends below the baseline, and subtract that value from the top of its bounding box. In the cases where it is impossible or impractical to determine the cap-height, the font’s ascent must be used.
rcap
Equal to the value of the cap unit on the root element.
ch
Represents the typical advance measure of European alphanumeric characters, and measured as the used advance measure of the “0” (ZERO, U+0030) glyph in the font used to render it. (The advance measure of a glyph is its advance width or height, whichever is in the inline axis of the element.)

Note: This measurement is an approximation (and in monospace fonts, an exact measure) of a single narrow glyph’s advance measure, thus allowing measurements based on an expected glyph count.

Note: The advance measure of a glyph depends on writing-mode and text-orientation as well as font settings, text-transform, and any other properties that affect glyph selection or orientation.

In the cases where it is impossible or impractical to determine the measure of the “0” glyph, it must be assumed to be 0.5em wide by 1em tall. Thus, the ch unit falls back to 0.5em in the general case, and to 1em when it would be typeset upright (i.e. writing-mode is vertical-rl or vertical-lr and text-orientation is upright).

Tests
rch
Equal to the value of the ch unit on the root element.
ic
Represents the typical advance measure of CJK letters, and measured as the used advance measure of the “水” (CJK water ideograph, U+6C34) glyph found in the font used to render it.

Note: This measurement is a typically an exact measure (in the few fonts with proportional fullwidth glyphs, an approximation) of a single fullwidth glyph’s