spec:css-color-4; type:property; text:color

spec:css-values-4; type: dfn;

text: determine the type of a calculation

text: keyword

text: identifier

spec:selectors-4; type: dfn; text: selector

spec:css-conditional-5; type:type; text:<size-feature>

spec:css-conditional-5; type:dfn; text:container feature

spec:css-conditional-5; type:type; text:<container-name>

spec:css-conditional-5; type:at-rule; text:@container

spec:css-conditional-5; type:type; text:<style-query>

spec:css-conditional-5; type:type; text:<style-query>

spec:css-mixins-1; type:dfn; text:custom function

spec:css-properties-values-api; type:dfn; text: supported syntax component names

spec:html; type:element; text:link

spec:infra; type:dfn; text:list

code, small { white-space: nowrap }

pre.value { font: inherit; white-space: pre-wrap; margin: 0; padding: 0; }

#propvalues td { text-align: right; }

#propvalues td + td { text-align: left; }

dt + dt::before { content: ", "; }

dl:not(.switch) dt { display: inline; }

td > small { display: block; }

ISSUE: <strong>This is a diff spec against <a href="https://www.w3.org/TR/css-values-4/">CSS Values and Units Level 4</a>.</strong>

This module extends [[CSS-VALUES-4]]

which replaces and extends the data type definitions in [[!CSS21]] sections

<a href="https://www.w3.org/TR/CSS21/about.html#value-defs">1.4.2.1</a>,

<a href="https://www.w3.org/TR/CSS21/syndata.html#values">4.3</a>,

and <a href="https://www.w3.org/TR/CSS21/aural.html#aural-intro">A.2</a>.

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

<!-- Big Text: syntax

███▌ █ ▐▌ █ █▌ █████▌ ███▌ █ █

█▌ █▌ ▐▌ █ █▌ █▌ █▌ ▐█ ▐█ █ █

█▌ █ ▐▌ ██▌ █▌ █▌ █▌ █▌ █ █

███▌ ▐▌█ █▌▐█ █▌ █▌ █▌ █▌ █

█▌ █▌ █▌ ██▌ █▌ █████▌ █ █

█▌ █▌ █▌ █▌ █▌ █▌ █▌ █▌ █ █

███▌ █▌ █▌ ▐▌ █▌ █▌ █▌ █ █

-->

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

Additionally,

<ol>

<li value=5>Boolean combinations of a conditional notation.

These are written using the <<boolean-expr[]>> notation,

and represent recursive expressions of boolean logic

using keywords and parentheses,

applied to the grammar specified in brackets,

e.g. <<boolean-expr[ ( &lt;media-feature&gt; ) ]>> to express [=media queries=].

</ol>

See [[css-values-4#component-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.

These values

(currently <<whole-value>>, <<declaration-value>>, and <<any-value>>)

are <dfn export>comma-containing productions</dfn>.

To accommodate these sorts of grammars unambiguously,

the [=comma-containing productions=] can be optionally wrapped in curly braces {}.

These braces are syntactic, not part of the actual value.

Specifically:

* A [=comma-containing production=] can either start with a "{" token, or not.

* If it does not start with a "{" token,

then it cannot contain commas or {} blocks,

in addition to whatever specific restrictions it defines for itself.

(The production stops parsing at that point,

so the comma or {} block is matched by the next grammar term instead;

probably the function's own argument-separating comma.)

* If it does start with a "{" token,

then the production matches just the {} block that the "{" token opens.

It represents the <em>contents</em> of that block,

and applies whatever specific restrictions it defines for itself

to those contents,

ignoring the {} block wrapper.

<div class="example">

For example, the grammar of the ''random-item()'' function is:

<pre>

random-item( <<random-caching-options>>, [<<declaration-value>>?]# )

</pre>

The ''#'' indicates comma-separated repetitions,

so randomly choosing between three keywords

would be written as normal for functions,

like:

<pre>

font-family: random-item(--x, serif, sans-serif, monospace);

</pre>

However, sometimes the values you want to choose between

need to include commas.

When this is the case,

wrapping the values in {}

allows their commas to be distinguished

from the function's argument-separating commas:

<pre>

font-family: random-item(--x, {Times, serif}, {Arial, sans-serif}, {Courier, monospace});

</pre>

This randomly chooses one of three font-family lists:

either ''Times, serif'', or ''Arial, sans-serif'', or ''Courier, monospace''.

This is not all-or-nothing;

you can use {} around <em>some</em> arguments that need it,

while leaving others bare when they don't need it.

You are also allowed to use {} around a value when it's not strictly required.

For example:

<pre>

font-family: random-item(--x, {Times, serif}, sans-serif, {monospace});

</pre>

This represents choosing between three font-family lists:

either ''Times, serif'', or ''sans-serif'', or ''monospace''.

However, this {}-wrapping is <em>only</em> allowed for some function arguments--

those defined as [=comma-containing productions=].

It's not valid for any other productions;

if you use {} around other function arguments,

it'll just fail to match the function's grammar

and become invalid.

For example, the following is <strong>invalid</strong>:

<pre>

background-image: linear-gradient(to left, {red}, magenta);

</pre>

</div>

Note: Because {} wrappers are allowed even when not explicitly required,

they can be used defensively around values

when the author isn't sure if they'll end up containing commas or not,

due to [=arbitrary substitution functions=] like ''var()''.

For example, <l property>''font-family: random-item(--x, {var(--list1)}, monospace)''</l>

will work correctly

regardless of whether the ''--list1'' custom property

contains a comma-separated list or not.

[=Functional notations=] are serialized without {} wrappers whenever possible.

The following generic productions are [=comma-containing productions=]:

* <<any-value>>

* <<whole-value>>

* <<declaration-value>>

For legacy compat reasons,

the <<declaration-value>> defined the fallback value for ''var()''

is a <dfn export>non-strict comma-containing production</dfn>.

It ignores the rules restricting what it can contain

when it does not start with a "{" token:

it is allowed to contain commas and {} blocks.

It still follows the standard [=comma-containing production=] rules

when it <em>does</em> start with a "{" token, however:

the fallback is just the contents of the {} block,

and doesn't include the {} wrapper itself.

Other contexts <em>may</em> define that they use [=non-strict comma-containing productions=],

but it <em>should</em> be avoided unless necessary.

Several contexts

(such as ''@media'', ''@supports'', ''if()'', ...)

specify conditions,

and allow combining those conditions with boolean logic (and/or/not/grouping).

Because they use the same non-trivial recursive syntax structure,

the special <dfn type><<boolean-expr>></dfn> production represents this pattern generically.

The <<boolean-expr[]>> notation wraps another value type in the square brackets within it,

e.g. &lt;boolean[ &lt;test&gt; ]&gt;,

and represents that value type alone as well as

boolean combinations

using the ''not'', ''and'', and ''or'' keywords

and grouping parenthesis.

It is formally equivalent to:

<xmp class=prod>

<boolean-expr[ <test> ]> = not <boolean-expr-group> | <boolean-expr-group>

[ [ and <boolean-expr-group> ]*

| [ or <boolean-expr-group> ]* ]

<boolean-expr-group> = <test> | ( <boolean-expr[ <test> ]> ) | <general-enclosed>

</xmp>

The <<boolean-expr[]>> production represents a true, false, or unknown value.

Its value is resolved using 3-value Kleene logic,

with top-level unknown values

(those not directly nested inside the grammar of another <<boolean-expr[]>>)

resolving to false unless otherwise specified;

see [[#boolean-logic]] for details.

<div class=example>

For example, the ''@container'' rule allows a wide variety of tests:

including size queries, style queries, and scroll-state queries.

All of these are arbitrarily combinable with boolean logic.

Using <<boolean-expr[]>>, the grammar for an ''@container'' query

could be written as:

<xmp class=prod>

<container-query> = <boolean-expr[ <cq-test> ]>

<cq-test> = (<size-query>) | style( <style-query> ) | scroll-state( <scroll-state-query> )

<size-query> = <boolean-expr[ ( <size-feature> ) ]> | <size-feature>

<style-query> = <boolean-expr[ ( <style-feature> ) ]> | <style-feature>

<scroll-state-query> = <boolean-expr[ ( <scroll-state-feature> ) ]> | <scroll-state-feature>

</xmp>

</div>

The <<general-enclosed>> branch of the logic allows for future compatibility--

unless otherwise specified new expressions in an older UA

will be parsed and considered “unknown”,

rather than invalidating the production.

For consistency with that allowance,

the <css>&lt;test></css> term in a <<boolean-expr[]>>

should be defined to match <<general-enclosed>>.

Some features in CSS,

such as the ''attr()'' function

or [=registered custom properties=],

allow you to specify how <em>another</em> value is meant to be parsed.

This is declared via the <<syntax>> production,

which resembles a limited form of the CSS [=value definition syntax=]

used in specifications to define CSS features,

and which represents a [=syntax definition=]:

A <<syntax-component>> consists of either

a <<syntax-type-name>> between &lt;&gt; (angle brackets),

which maps to one of the [=supported syntax component names=],

or an <<ident>>, which represents any [=keyword=].

Additionally,

a <<syntax-component>> may contain a [[css-properties-values-api-1#multipliers|multiplier]],

which indicates a [=list=] of values.

Note: This means that <code>&lt;length&gt;</code>

and <code>length</code> are two different types:

the former describes a <<length>>,

whereas the latter describes a [=keyword=] <code>length</code>.

Multiple <<syntax-component>>s may be [[css-properties-values-api-1#combinator|combined]]

with a <code>|</code> <<delim-token>>,

causing the syntax components to be matched

against a value

in the specified order.

<xmp class='lang-css'>

<percentage> | <number> | auto

</xmp>

The above, when parsed as a <<syntax>>,

would accept <<percentage>> values,

<<number>> values,

as well as the keyword <code>auto</code>.

<xmp class='lang-css'>

red | <color>

</xmp>

The [=syntax definition=] resulting from the above <<syntax>>,

when used as a grammar for [=parse|parsing=],

would match an input <code>red</code> as an [=identifier=],

but would match an input <code>blue</code> as a <<color>>.

The <code>*</code> <<delim-token>> represents the [=universal syntax definition=].

The <code>&lt;transform-list&gt;</code> production

is a convenience form equivalent to <code>&lt;transform-function&gt;+</code>.

<span class=note>Note that <code>&lt;transform-list&gt;</code> may not

be followed by a <<syntax-multiplier>>.</span>

[=Whitespace=] is not allowed

between the angle bracket <<delim-token>>s (<code>&lt;</code> <code>&gt;</code>)

and the <<syntax-type-name>> they enclose,

nor is [=whitespace=] allowed to precede a <<syntax-multiplier>>.

Note: The [=whitespace=] restrictions also apply to <code>&lt;transform-list&gt;</code>.

A <<syntax-string>> is a <<string>>

whose value successfully [=CSS/parses=] as a <<syntax>>,

and represents the same value as that <<syntax>> would.

Note: <<syntax-string>> mostly exists for historical purposes;

before <<syntax>> was defined,

the ''@property'' rule used a <<string>> for this purpose.

The purpose of a <<syntax>>

is usually to specify how to parse another value

(such as the value of a [=registered custom property=],

or an attribute value in ''attr()'').

However, the generic [=CSS/parse something according to a CSS grammar=] algorithm

returns an unspecified internal structure,

since parse results might be ambiguous

and need further massaging.

To avoid these issues and get a well-defined result,

use [=parse with a <syntax>=]:

To <dfn export>parse with a <<syntax>></dfn>

given a [=string=] or [=list=] or [=CSS/component values=] |values|,

a <<syntax>> value |syntax|,

and optionally an element |el| for context,

perform the following steps.

It returns either CSS values,

or the [=guaranteed-invalid value=].

1. [=Parse a list of component values=] from |values|,

and let |raw parse| be the result.

2. If |el| was given,

[=substitute arbitrary substitution functions=] in |raw parse|,

and set |raw parse| to that result.

3. [=CSS/parse=] |values| according to |syntax|,

with a ''*'' value treated as <code><<declaration-value>>?</code>,

and let |parsed result| be the result.

If |syntax| used a ''|'' combinator,

let |parsed result| be the parse result from the first matching clause.

4. If |parsed result| is failure,

return the [=guaranteed-invalid value=].

5. Assert: |parsed result| is now a well-defined list of one or more CSS values,

since each branch of a <<syntax>> defines an unambiguous parse result

(or the ''*'' syntax is unambiguous on its own).

6. Return |parsed result|.

Note: This algorithm does not resolved the parsed values

into [=computed values=];

the context in which the value is used will usually do that already,

but if not,

the invoking algorithm will need to handle that on its own.

See <a href="https://www.w3.org/TR/css-values-4/">CSS Values and Units Level 4</a>.

<!-- Big Text: url

█▌ █▌ ████▌ █▌

█▌ █▌ █▌ █▌ █▌

█▌ █▌ █▌ █▌ █▌

█▌ █▌ ████▌ █▌

█▌ █▌ █▌▐█ █▌

█▌ █▌ █▌ ▐█ █▌

███▌ █▌ █▌ █████

-->

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

<dfn><<request-url-modifier>></dfn>s are <<url-modifier>>s

that affect the <<url>>’s resource [=/request=]

by applying associated [=URL request modifier steps=].

See [[css-values-4#url-processing]].

This specification defines the following <<request-url-modifier>>s:

<pre class=prod>

<dl dfn-for="<request-url-modifier>">

<dt><dfn><<crossorigin-modifier>></dfn> = <dfn function lt="crossorigin()">crossorigin</dfn>(<dfn value>anonymous</dfn> | <dfn value>use-credentials</dfn>)

<dd>

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

<dt><dfn><<integrity-modifier>></dfn> = <dfn function lt="integrity()">integrity</dfn>(<<string>>)

<dd>

The [=URL request modifier steps=] for this modifier given [=/request=] |req|

are to set [=/request=]'s [=request/integrity metadata=]

to the given <<string>>.

<dt><dfn><<referrerpolicy-modifier>></dfn> = <dfn function lt="referrerpolicy()">referrerpolicy</dfn>(<dfn value>no-referrer</dfn> | <dfn value>no-referrer-when-downgrade</dfn> | <dfn value>same-origin</dfn> | <dfn value>origin</dfn> | <dfn value>strict-origin</dfn> | <dfn value>origin-when-cross-origin</dfn> | <dfn value>strict-origin-when-cross-origin</dfn> | <dfn value>unsafe-url</dfn>)

<dd>

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.

</dl>

<div algorithm>

To <dfn export>apply request modifiers from URL value</dfn>

given a [=/request=] |req|

and a <<url>> |url|,

call the [=URL request modifier steps=] for |url|'s <<request-url-modifier>>s in sequence

given |req|.

</div>

<!-- Big Text: position

████▌ ███▌ ███▌ ████ █████▌ ████ ███▌ █ █▌

█▌ █▌ █▌ █▌ █▌ █▌ ▐▌ █▌ ▐▌ █▌ █▌ █▌ █▌

█▌ █▌ █▌ █▌ █▌ ▐▌ █▌ ▐▌ █▌ █▌ ██▌ █▌

████▌ █▌ █▌ ███▌ ▐▌ █▌ ▐▌ █▌ █▌ █▌▐█ █▌

█▌ █▌ █▌ █▌ ▐▌ █▌ ▐▌ █▌ █▌ █▌ ██▌

█▌ █▌ █▌ █▌ █▌ ▐▌ █▌ ▐▌ █▌ █▌ █▌ █▌

█▌ ███▌ ███▌ ████ █▌ ████ ███▌ █▌ ▐▌

-->

The <dfn><<position>></dfn> value specifies the position

of an [=alignment subject=] (e.g. a background image)

inside an [=alignment container=] (e.g. its [=background positioning area=])

as a pair of offsets between the specified edges

(defaulting to the left and top).

Its syntax is:

<pre class=prod>

If only one value is specified (<<position-one>>),

the second value is assumed to be ''center''.

If two values are given (<<position-two>>),

a <<length-percentage>> as the first value represents

the horizontal position as the offset between

the left edges of the [=alignment subject=] and [=alignment container=],

and a <<length-percentage>> as the second value represents

the vertical position as an offset between their top edges.

If both keywords are one of ''<position>/start'' or ''<position>/end'',

the first one represents the [=block axis=]

and the second the [=inline axis=].

Note: A pair of axis-specific keywords can be reordered,

while a combination of keyword and length or percentage cannot.

So ''center left'' or ''inline-start block-end'' is valid,

while ''50% left'' is not.

''<position>/start'' and ''<position>/end'' aren't axis-specific,

so ''start end'' and ''end start'' represent two different positions.

If four values are given (<<position-four>>)

then each <<length-percentage>> represents an offset between

the edges specified by the preceding keyword.

For example, ''background-position: bottom 10px right 20px''

represents a ''10px'' vertical offset up from the bottom edge

and a ''20px'' horizontal offset leftward from the right edge.

Positive values represent an offset <em>inward</em>

from the edge of the [=alignment container=].

Negative values represent an offset <em>outward</em>

from the edge of the [=alignment container=].

<div class="example">

The following declarations give the stated (horizontal, vertical)

offsets from the top left corner:

<pre>

background-position: left 10px top 15px; /* 10px, 15px */

background-position: left top ; /* 0px, 0px */

background-position: 10px 15px; /* 10px, 15px */

background-position: left 15px; /* 0px, 15px */

background-position: 10px top ; /* 10px, 0px */

</pre>

</div>

<div class=example>

<<position>>s can also be relative to other corners than the top left.

For example, the following puts the background image

10px from the bottom and 3em from the right:

<pre>background-position: right 3em bottom 10px</pre>

</div>

The [=computed value=] of a <<position>> is

a pair of offsets (horizontal and vertical),

each given as a computed <<length-percentage>> value,

representing the distance between the left edges and top edges (respectively)

of the [=alignment subject=] and [=alignment container=].

<dl dfn-for="<position>" dfn-type=value>

<dt><dfn><<length-percentage>></dfn>

<dd>

A <<length-percentage>> value specifies the size of the offset

between the specified edges of the [=alignment subject=] and [=alignment container=].

For example, for ''background-position: 2cm 1cm'',

the top left corner of the background image is placed

2cm to the right and 1cm below

the top left corner of the [=background positioning area=].

A <<percentage>> for the horizontal offset is relative to

(<var ignore>width of [=alignment container=]</var> - <var ignore>width of [=alignment subject=]</var>).

A <<percentage>> for the vertical offset is relative to

(<var ignore>height of [=alignment container=]</var> - <var ignore>height of [=alignment subject=]</var>).

<div class=example>

For example, with a value pair of ''0% 0%'',

the upper left corner of the [=alignment subject=] is aligned with

the upper left corner of the [=alignment container=]

A value pair of ''100% 100%'' places

the lower right corner of the [=alignment subject=]

in the lower right corner of the [=alignment container=].

With a value pair of ''75% 50%'',

the point 75% across and 50% down the [=alignment subject=]

is to be placed at the point 75% across and 50% down the [=alignment container=].

<figure>

<img src="images/bg-pos.png"

<figcaption>

Diagram of the meaning of ''background-position: 75% 50%''.

</figcaption>

</figure>

</div>

<dt><dfn>top</dfn>

<dt><dfn>right</dfn>

<dt><dfn>bottom</dfn>

<dt><dfn>left</dfn>

<dd>

Offsets the top/left/right/bottom edges (respectively)

of the [=alignment subject=] and [=alignment container=]

by the specified amount (defaulting to ''0%'')

in the corresponding axis.

<dt><dfn>y-start</dfn>

<dt><dfn>y-end</dfn>

<dt><dfn>x-start</dfn>

<dt><dfn>x-end</dfn>

<dd>

Computes the same as the physical edge keyword

corresponding to the [=start=]/[=end=] side

in the [=y-axis|y=]/[=x-axis|x=] axis.

<dt><dfn>block-start</dfn>

<dt><dfn>block-end</dfn>

<dt><dfn>inline-start</dfn>

<dt><dfn>inline-end</dfn>

<dd>

Computes the same as the physical edge keyword

corresponding to the [=start=]/[=end=] side

in the [=block axis|block=]/[=inline axis|inline=] axis.

<dt><dfn>center</dfn>

<dd>

Computes to a ''50%'' offset in the corresponding axis.

</dl>

Unless otherwise specified, the [=flow-relative=] keywords are resolved

according to the [=writing mode=] of the element on which the value is specified.

Note: The 'background-position' property also accepts a three-value syntax.

This has been disallowed generically because it creates parsing ambiguities

when combined with other length or percentage components in a property value.

ISSUE(9690): Need to define how this syntax would expand to the longhands of 'background-position'

if e.g. ''var()'' is used for some (or all) of the components.

When specified in a grammar alongside other keywords, <<length>>s, or <<percentage>>s,

<<position>> is <em>greedily</em> parsed;

it consumes as many components as possible.

<div class=example>

For example,

'transform-origin' defines a 3D position

as (effectively) ''<<position>> <<length>>?''.

A value such as ''left 50px''

will be parsed as a 2-value <<position>>,

with an omitted z-component;

on the other hand,

a value such as ''top 50px''

will be parsed as a single-value <<position>>

followed by a <<length>>.

</div>

When serializing the [=specified value=] of a <<position>>:

<dl class=switch>

<dt>If only one component is specified:

<dd>

* The implied <a value spec="css-backgrounds-3">center</a> keyword is added,

and a 2-component value is serialized.

<dt>If two components are specified:

<dd>

* Keywords are serialized as keywords.

* <<length-percentage>>s are serialized as <<length-percentage>>s.

* Components are serialized horizontal first, then vertical.

<dt>If four components are specified:

<dd>

* Keywords and offsets are both serialized.

* Components are serialized horizontal first, then vertical;

alternatively [=block-axis=] first, then [=inline-axis=].

</dl>

Note: <<position>> values are never serialized as a single value,

even when a single value would produce the same behavior,

to avoid causing parsing ambiguities in some grammars

where a <<position>> is placed next to a <<length>>,

such as 'transform-origin'.

The [=computed value=] of a <<position>>

is serialized as a pair of <<length-percentage>>s

representing offsets from the left and top edges, in that order.

<l spec=css-values-4>[=Interpolation=]</l> of <<position>> is defined as

the independent interpolation of each component (x, y)

normalized as an offset from the top left corner

as a <<length-percentage>>.

<l spec=css-values-4>[=value addition|Addition=]</l> of <<position>> is likewise defined as

the independent <l spec=css-values-4>[=value addition|addition=]</l> each component (x, y)

normalized as an offset from the top left corner

as a <<length-percentage>>.

<!-- Big Text: interp

████ █ █▌ █████▌ █████▌ ████▌ ████▌

▐▌ █▌ █▌ █▌ █▌ █▌ █▌ █▌ █▌

▐▌ ██▌ █▌ █▌ █▌ █▌ █▌ █▌ █▌

▐▌ █▌▐█ █▌ █▌ ████ ████▌ ████▌

▐▌ █▌ ██▌ █▌ █▌ █▌▐█ █▌

▐▌ █▌ █▌ █▌ █▌ █▌ ▐█ █▌

████ █▌ ▐▌ █▌ █████▌ █▌ █▌ █▌

-->

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 <dfn noexport>progress value</dfn>)

from one value (the <dfn noexport>progress start value</dfn>)

to another value (the <dfn noexport>progress end value</dfn>).

They allow drawing a progress ratio from

[=math functions=], [=media features=], and [=container features=],

respectively,

following a common syntactic pattern:

<pre class=prod>

Each resolves to a <<number>>

by [=calculating a progress function=].

<div algorithm>

To <dfn export>calculate a progress function</dfn>,

given a [=progress value=],

[=progress start value=],

and [=progress end value=]:

: If the [=progress start value=] and [=progress end value=] are different values

:: <code>([=progress value=] - [=progress start value=]) / ([=progress end value=] - [=progress start value=])</code>.

: If the [=progress start value=] and [=progress end value=] are the same value

:: 0, -∞, or +∞,

depending on whether [=progress value=]

is equal to, less than, or greater than

the shared value.

Note: The return value is a plain <<number>>,

not [=made consistent=] with its arguments by default.

</div>

The resulting number can then be input into other calculations,

such as a [=math function=]

or a [=mix notation=].

The <dfn>progress()</dfn> functional notation

returns a <<number>> value

representing the position of one [=calculation=]

(the [=progress value=])

between two other [=calculations=]

(the [=progress start value=]

and [=progress end value=]).

''progress()'' is a [=math function=].

The syntax of ''progress()'' is defined as follows:

<pre class=prod>

where the first, second, and third <<calc-sum>> values represent

the [=progress value=], [=progress start value=], and [=progress end value=],

respectively.

The argument [=calculations=] can resolve to any <<number>>, <<dimension>>, or <<percentage>>,

but must have a [=consistent type=]

or else the function is invalid.

The value of ''progress()'' is a <<number>>,

determined by [=calculating a progress function=],

then [=made consistent=] with the [=consistent type=] of its arguments.

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,

so it's a [=math function=].

Similar to the ''progress()'' notation,

the <dfn>media-progress()</dfn> functional notation

returns a <<number>> 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:

<pre class=prod>

where the value of the [=media feature=] corresponding to <<mf-name>>

represents the [=progress value=],

and the two <<calc-sum>> values represent

the [=progress start value=] and [=progress end value=],

respectively.

The specified [=media feature=] must be a valid “range” type feature,

the specified [=progress start value=] and [=progress end value=]

must be valid values for the specified [=media query=],

and both [=calculation=] values must have a [=consistent type=],

or else the function is invalid.

The [=progress start value=] and [=progress end value=] [=calculations=]

are interpreted as specified for the [=media feature=]

(rather than as specified by the context the function is used in).

The value of ''media-progress()'' is a <<number>>,

determined by [=calculating a progress function=].

Note: ''media-progress()'' is <em>not</em> a [=math function=];

it's just a function that evaluates to a <<number>>.

The <dfn>container-progress()</dfn> 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:

<pre class=prod>

where <<mf-name>> represents a [=size feature=]

and the optional <<container-name>> component specifies

the named containers to consider when selecting a container

to resolve them against.

The value of the [=size feature=] is the [=progress value=],

and the two <<calc-sum>> values represent

the [=progress start value=] and [=progress end value=],

respectively.

The specified <<mf-name>> must be a valid [=size feature=],

the specified [=progress start value=] and [=progress end value=]

must be valid values for that [=size feature=],

and both [=calculation=] values must have a [=consistent type=],

or else the function is invalid.

''container-progress()'' is only valid in a property value context;

it cannot be used in, for example, a [=media query=].

The [=progress start value=] and [=progress end value=] [=calculations=]

are interpreted as specified for the [=size feature=]

(rather than as specified by the context the function is used in).

If no appropriate containers are found,

''container-progress()'' resolves its <<size-feature>> query

against the [=small viewport size=].

The value of ''media-progress()'' is a <<number>>,

determined by [=calculating a progress function=].

Note: ''container-progress()'' is <em>not</em> a [=math function=];

it's just a function that evaluates to a <<number>>.

<!-- Big Text: *-mix()

█ █ ████ █ █ ██ ██

█ █ ██ ██ ▐▌ █ █ █▌ ▐█

█ █ █▌█ █▐█ ▐▌ █ █ █▌ ▐█

███████ ████▌ █▌ █ ▐█ ▐▌ █ █▌ ▐█

█ █ █▌ ▐█ ▐▌ █ █ █▌ ▐█

█ █ █▌ ▐█ ▐▌ █ █ █▌ ▐█

█▌ ▐█ ████ █ █ ██ ██

-->

ISSUE(6245): This feature <a href="https://css.typetura.com/ruleset-interpolation/explainer/">does not handle multiple breakpoints very well</a>,

and <a href="https://github.com/w3c/csswg-drafts/issues/6245#issuecomment-2469190377">might need to be redesigned</a>.

Several <dfn>mix notations</dfn> in CSS

allow representing the interpolation of two values,

the <dfn>mix start value</dfn> and the <dfn>mix end value</dfn>,

at a given point in progress between them (the <dfn>mix progress value</dfn>).

These [=functional notations=] follow the syntactic pattern:

<pre class=prod>

The [=mix notations=] in CSS include:

* ''calc-mix()'',

for interpolating <<length>>, <<percentage>>, <<time>>,

and other dimensions representable in ''calc()'' expressions

* ''color-mix()'',

for interpolating two <<color>> values

* ''cross-fade()'',

for interpolating <<image>> values

* ''palette-mix()'',

for interpolating two 'font-palette' values

and finally the generic ''mix()'' notation,

which can represent the interpolation of any property's values

(but only the property's entire value, not individual components).

Note: The ''cross-fade()'' notation

also has an alternative syntax

that allows for mixing more than two values,

but does not allow for the more complex expressions of <<progress>>.

ISSUE: The ''mix()'' notation also has a variant that takes a set of keyframes.

It does this by referring to an ''@keyframes'' rule,

and pulling the corresponding property declaration out of that.

It would be nice to allow the other mix notations to take keyframe also,

but how would we represent a set of keyframes for a [=component value=]

(rather than a full property value)?

The <dfn><<progress>></dfn> value type represents

the [=mix progress value=] in a [=mix notation=],

and ultimately resolves to a percentage.

It can, however, draw that percentage value

from sources such as media queries and animation timelines,

and can also convert it through an [=easing function=]

before using it for interpolation.

Its syntax is defined as follows:

<pre class=prod>

where:

<dl dfn-type=value dfn-for="<progress>">

<dt><dfn><<percentage-token>></dfn>

<dd>