Title: CSS Values and Units Module Level 5
Group: CSSWG
Shortname: css-values
Level: 5
Status: ED
Work Status: Exploring
ED: https://drafts.csswg.org/css-values-5/
TR: https://www.w3.org/TR/css-values-5/
Editor: Tab Atkins, Google, http://xanthir.com/contact/, w3cid 42199
Editor: Elika J. Etemad / fantasai, Apple, http://fantasai.inkedblade.net/contact, w3cid 35400
Editor: Miriam E. Suzanne, Invited Expert, http://miriamsuzanne.com/contact, w3cid 117151
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.
Ignored Terms: , containing block, property
Ignored Vars: Cn+1, n
Inline Github Issues: no
Default Highlight: css

Introduction

ISSUE: This is a diff spec against CSS Values and Units Level 4.

Module Interactions

This module extends [[CSS-VALUES-4]] which replaces and extends the data type definitions in [[!CSS21]] sections 1.4.2.1, 4.3, and A.2.

Textual Data Types

See [[css-values-4#textual-values]].

Value Definition Syntax

See [[css-values-4#value-defs]].

Functional Notation Definitions

See [[css-values-4#component-functions]].

Commas and Semicolons in Functions

[=Functional notation=] often uses commas to separate parts of its internal grammar. However, some functions (such as ''mix()'') allow values that, themselves, can contain commas. To accommodate these sorts of grammars unambiguously, commas in functional grammars are implicitly upgradeable to semicolons in Level 5; that is, commas in a [=functional notation=]'s grammar can instead be represented as <>s. This is all-or-nothing: either every comma in the [=functional notation=] must be written as a semicolon, or none of them must be. When the [=functional notation=]’s arguments are parsed, initially commas in the grammar match only <>s; if a <> is encountered, then the [=functional notation=] is re-interpreted with all commas in the grammar replaced by <>s. Commas contained in productions defined as comma-containing productions (such as <> or <>) are not implicitly upgradeable. Even when a [=functional notation=] is being re-interpreted with semicolons, these productions end when a <> is encountered.
The following examples are both equivalent declarations:
			list-style: toggle(disc, circle, square);
			list-style: toggle(disc; circle; square);
		
however, this is different (and invalid):
			list-style: toggle(disc, circle; square);
		
because it represents toggling between two values (disc, circle and square) and disc, circle is not a valid 'list-style' value. This ability is important, because sometimes [=functional notation=] arguments need to include commas. For example, in 'font-family':
			font-family: random-item(Times, serif; Arial, sans-serif; Courier, monospace);
		
This randomly chooses one of three font-family lists: either ''Times, serif'', or ''Arial, sans-serif'', or ''Courier, monospace''. But if only single fonts were needed for each choice, commas could have been used to separate them:
		font-family: random-item(serif, sans-serif, monospace);
		
[=Functional notations=] are serialized with commas (rather than semicolons) whenever possible. The following generic productions are [=comma-containing productions=]: * <> * <> * <> Issue: The functions defined in this spec with semicolons in their grammar need fixing to just use commas, now.

Resource Locators: the <> type

See [[css-values-4#urls]].

Request URL Modifiers

<>s are <>s that affect the <>’s resource [=/request=] by applying associated [=URL request modifier steps=]. See [[css-values-4#url-processing]]. This specification defines the following <>s:
		<> = <> | <> | <>
		<> = crossorigin(anonymous | use-credentials)
		<> = integrity(<>)
		<> = referrerpolicy(no-referrer | no-referrer-when-downgrade | same-origin | origin | strict-origin | origin-when-cross-origin | strict-origin-when-cross-origin | unsafe-url)
	
<> = crossorigin(anonymous | use-credentials)
The [=URL request modifier steps=] for this modifier given [=/request=] |req| are: 1. Set [=/request=]'s [=request/mode=] to "cors". 2. If the given value is ''use-credentials'', set [=/request=]'s [=request/credentials mode=] to "include".
<> = integrity(<>)
The [=URL request modifier steps=] for this modifier given [=/request=] |req| are to set [=/request=]'s [=request/integrity metadata=] to the given <>.
<> = referrerpolicy(no-referrer | no-referrer-when-downgrade | same-origin | origin | strict-origin | origin-when-cross-origin | strict-origin-when-cross-origin | unsafe-url)
The [=URL request modifier steps=] for this modifier given [=/request=] |req| are to set [=/request=]'s [=request/referrer policy=] to the {{ReferrerPolicy}} that matches the given value.
To apply request modifiers from URL value given a [=/request=] |req| and a <> |url|, call the [=request modifier steps=] for |url|'s <>s in sequence given |req|.

Interpolation Progress Functional Notations

ISSUE(6245): This section is an exploratory draft, and not yet approved by the CSSWG. The ''progress()'', ''media-progress()'', and ''container-progress()'' [=functional notations=] represent the proportional distance of a given value (the progress value) from one value (the progress start value) to another value (the progress end value). They allow drawing a progress ratio from [=math functions=], [=media features=], and [=container features=], respectively, following a common syntactic pattern:
		progress-function() = progress-function( progress value from start value to end value )
	
The resulting ratio can then be input into other calculations, such as a [=math function=] or a [=mix notation=].

Calculated Progress Values: the ''progress()'' notation

The progress() functional notation returns a <> value representing the position of one [=calculation=] (the [=progress value=]) between two other [=calculations=] (the [=progress start value=] and [=progress end value=]). The argument [=calculations=] can resolve to any <>, <>, or <>, but must have a [=consistent type=] or else the function is invalid. The result will be a <>, [=made consistent=] with the [=consistent type=] of the arguments. The syntax of ''progress()'' is defined as follows:
		<> = progress(<> from <> to <>)
	
where the first, second, and third <> values represent the [=progress value=], [=progress start value=], and [=progress end value=], respectively. The value returned by a valid ''progress()'' notation is (progress value - start value) / (end value - start value), as a <>. ISSUE: Do we need a ''percent-progress()'' notation, or do enough places auto-convert that it's not necessary? Note: The ''progress()'' function is essentially syntactic sugar for a particular pattern of ''calc()'' notations.

Media Query Progress Values: the ''media-progress()'' notation

Similar to the ''progress()'' notation, the media-progress() functional notation returns a <> value representing current value of the specified [=media query=] [[!MEDIAQUERIES-4]] as a [=progress value=] between two explicit values of the [=media query=] (as the [=progress start value=] and [=progress end value=]). The syntax of ''media-progress()'' is defined as follows:
		<> = media-progress(<> from <> to <>)
	
The value returned by a valid ''media-progress()'' notation is progress value / (end value - start value, as a <>. The specified [=media query=] must be a valid “range” type query, and its specified [=progress start value=] and [=progress end value=] must be valid values for the specified [=media query=], or else the function is invalid. The two input [=calculations=] but must have a [=consistent type=] or else the function is invalid. The result will be a <>, [=made consistent=] with the [=consistent type=] of the arguments.

Container Query Progress Values: the ''container-progress()'' notation

The container-progress() functional notation is identical to the ''media-progress()'' functional notation, except that it accepts [=container features=] [[!CSS-CONTAIN-3]] in place of [=media features=]. The syntax of ''container-progress()'' is defined as follows:
		<> = container-progress(<> [ of <> ]? from <> to <>)
	
where the optional <> component specifies the named containers to consider when selecting a container to resolve against. The two input [=calculations=] but must have a [=consistent type=] or else the function is invalid. The result will be a <>, [=made consistent=] with the [=consistent type=] of the arguments. If no appropriate containers are found, ''container-progress()'' resolves its <> query against the [=small viewport size=].

Mixing and Interpolation Notations: the *-mix() family

ISSUE(6245): This section is an exploratory draft, and not yet approved by the CSSWG. Several mix notations in CSS allow representing the interpolation of two values, the mix start value and the mix end value, at a given point in progress between them (the mix progress value). These [=functional notations=] follow the syntactic pattern:
		mix-function() = mix-function( <>, [=mix start value|start-value=], [=mix end value|end-value=] )
	
The [=mix notations=] in CSS include: * ''calc-mix()'', for interpolating <>, <>, <