Overview.bs

<pre class='metadata'>
Title: CSS Functions and Mixins Module
Shortname: css-mixins
Level: 1
Status: ED
Work Status: Exploring
Group: CSSWG
ED: https://drafts.csswg.org/css-mixins/
TR: https://www.w3.org/TR/css-mixins-1/
Editor: Miriam E. Suzanne, Invited Expert, http://miriamsuzanne.com/contact, w3cid 117151
Editor: Tab Atkins-Bittner, Google, http://xanthir.com/contact/, w3cid 42199
Abstract: This module provides the ability to define custom functional notations.
Default Highlight: css
</pre>

<pre class=link-defaults>
spec:infra; type:dfn; text:list
spec:css-properties-values-api; type:dfn; text:supported syntax component name
spec:css-properties-values-api; type:dfn; text:syntax component
spec:css-syntax-3; type:dfn; text:descriptor;
spec:css-values-4; type:dfn; text:keyword;
spec:css-values-4; type:dfn; text:identifier;
</pre>

<!-- Big Text: intro

████ █    █▌ █████▌ ████▌   ███▌
 ▐▌  █▌   █▌   █▌   █▌  █▌ █▌  █▌
 ▐▌  ██▌  █▌   █▌   █▌  █▌ █▌  █▌
 ▐▌  █▌▐█ █▌   █▌   ████▌  █▌  █▌
 ▐▌  █▌  ██▌   █▌   █▌▐█   █▌  █▌
 ▐▌  █▌   █▌   █▌   █▌ ▐█  █▌  █▌
████ █▌   ▐▌   █▌   █▌  █▌  ███▌
-->

Introduction {#intro}
=====================

	<em>This section is not normative.</em>

Issue: TODO

<!-- Big Text: @function

 ████▌  █████▌ █▌  █▌ █    █▌  ███▌  █████▌ ████  ███▌  █    █▌
█▌   █▌ █▌     █▌  █▌ █▌   █▌ █▌  █▌   █▌    ▐▌  █▌  █▌ █▌   █▌
█▌▐█ █▌ █▌     █▌  █▌ ██▌  █▌ █▌       █▌    ▐▌  █▌  █▌ ██▌  █▌
█▌▐█ █▌ ████   █▌  █▌ █▌▐█ █▌ █▌       █▌    ▐▌  █▌  █▌ █▌▐█ █▌
█▌ ██▌  █▌     █▌  █▌ █▌  ██▌ █▌       █▌    ▐▌  █▌  █▌ █▌  ██▌
█▌      █▌     █▌  █▌ █▌   █▌ █▌  █▌   █▌    ▐▌  █▌  █▌ █▌   █▌
 ████▌  █▌      ███▌  █▌   ▐▌  ███▌    █▌   ████  ███▌  █▌   ▐▌
-->

Defining Custom Functions {#defining-custom-functions}
======================================================

	A [=custom function=] can be thought of as an advanced [=custom property=],
	which instead of being substituted by a single fixed value
	provides its substitution value based on [=function parameters=]
	and [=local variables=].

	Whenever a declaration's value contains a reference to a [=custom function=]
	(a <<dashed-function>>),
	the value behaves as if it contained a ''var()'',
	with the actual check against the property's grammar delayed until computed-value time.

	<div class='example'>
		A simple [=custom function=] to negate a value can be defined as follows:
		<pre class='lang-css'>
		@function --negative (--value) {
		  result: calc(-1 * var(--value));
		}
		</pre>
		Then, that function can be referenced with <code>--negative()</code>
		in some declaration (assuming <code>--gap</code> is defined elsewhere):
		<pre class='lang-css'>
		html { padding: --negative(var(--gap)); }
		</pre>
	</div>

	A <dfn>custom function</dfn> consists of a name (<<function-name>>),
	a list of [=function parameter|parameters=],
	a list of [=function dependency|dependencies=],
	a function body,
	and optionally a <dfn>return type</dfn> described by a [=syntax definition=].

	A <dfn>function parameter</dfn> consists of a name (<<custom-property-name>>);
	optionally a <dfn>parameter type</dfn>, described by a [=syntax definition=];
	and optionally a <dfn>default value</dfn>.

	A <dfn>function dependency</dfn>,
	is a special [=function parameter=],
	that represents
	a [=local variable=], [=function parameter=], or [=custom property=]
	being implicitly passed as an argument from the calling context.

The <dfn>@function</dfn> Rule {#function-rule}
----------------------------------------------

The ''@function'' rule defines a [=custom function=],
and its syntax is:

<pre class="prod def" nohighlight>
&lt;@function> = @function <<function-name>> [ ( <<function-parameter-list>> ) ]?
	[ using ( <<function-dependency-list>> ) ]?
	[ returns <<css-type>> ]?
{
	<<declaration-rule-list>>
}

<dfn><<function-name>></dfn> = <<dashed-ident>>
<dfn><<function-parameter-list>></dfn> = <<function-parameter>>#
<dfn><<function-dependency-list>></dfn> = <<function-parameter>>#
<dfn><<function-parameter>></dfn> = <<custom-property-name>> <<css-type>>? [ : <<declaration-value>> ]?
<dfn><<css-type>></dfn> = <<syntax-component>> | <<type()>>
<dfn>&lt;type()></dfn> = type( <<syntax>> )
</pre>

The name of the resulting [=custom function=] is given by the <<function-name>>,
the [=function parameters=] are optionally given by <<function-parameter-list>>,
the [=function dependencies=] are optionally given by <<function-dependency-list>>,
and the [=return type=] is optionally given by the <<css-type>> following the "returns" keyword.

<div class='example'>
	If the <<css-type>> of a [=function parameter=],
	[=function dependency=],
	or [=custom function=] return value
	can be described by a single <<syntax-component>>,
	then the <code>type()</code> function may be omitted:

	<pre class='lang-css'>
	@function --foo(--a &lt;length&gt;) { /* ... */ }
	@function --foo(--a &lt;color&gt;) { /* ... */ }
	@function --foo(--a &lt;length&gt;+) { /* ... */ }
	</pre>

	However,
	any <<syntax>> that requires a <<combinator>>
	needs to be wrapped in the <code>type()</code> function:

	<pre class='lang-css'>
	@function --foo(--a type(&lt;number&gt; | &lt;percentage&gt;)) { /* ... */ }
	</pre>
</div>

Issue: Should duplicates be disallowed <em>across</em> parameters/dependencies
	as well?

If more than one ''@function'' exists for a given name,
then the rule in the stronger cascade layer wins,
and rules defined later win within the same layer.

The <<function-name>> of a ''@function'' rule is a [=tree-scoped name=].

If the <<function-parameter-list>>
contains the same <<custom-property-name>> more than once,
or if the <<function-dependency-list>>
contains the same <<custom-property-name>> more than once,
then the ''@function'' rule is invalid.

The body of a ''@function'' rule accepts [=conditional group rules=],
such as ''@media''.
Additionally, it accepts the following descriptors:

	* The '@function/result' descriptor,
		which determines the result of [=evaluating a custom function|evaluating the function=].
	* [=Custom properties=],
		acting like [=local variable=] descriptors.

Unknown descriptors are invalid and ignored,
but do not make the ''@function'' rule itself invalid.

The '@function/result' Descriptor {#the-result-descriptor}
----------------------------------------------------------

<pre class='descdef'>
Name: result
Value: <<declaration-value>>?
For: @function
Initial: n/a (see prose)
</pre>

The '@function/result' descriptor
determines the result of [=evaluate a custom function|evaluating=]
the [=custom function=] that is defined by a ''@function'' rule.
Using [=locally substitute a var()|locally substituted=] ''var()'' functions,
it can reference [=function parameters=], [=function dependencies=], [=local variables=],
as well as other [=custom functions=] via <<dashed-function>>s.

The '@function/result' descriptor itself does not have a type,
but its [=resolved local value|resolved=] value is type checked
during the [=substitute a dashed function|substitution=] of a <<dashed-function>>.

<!-- Big Text: using

█▌  █▌  ███▌  ████ █    █▌  ███▌
█▌  █▌ █▌  █▌  ▐▌  █▌   █▌ █▌  █▌
█▌  █▌ █▌      ▐▌  ██▌  █▌ █▌
█▌  █▌  ███▌   ▐▌  █▌▐█ █▌ █▌ ██▌
█▌  █▌     █▌  ▐▌  █▌  ██▌ █▌  █▌
█▌  █▌ █▌  █▌  ▐▌  █▌   █▌ █▌  █▌
 ███▌   ███▌  ████ █▌   ▐▌  ███▌
-->

Using Custom Functions {#using-custom-functions}
================================================

Similar to how the value of a [=custom property=] can be substituted
into the value of another property with ''var()'',
the result of a [=custom function=] evaluation can be substituted
with a <<dashed-function>>.

A <dfn><<dashed-function>></dfn> is a [=functional notation=]
whose function name starts with two dashes (U+002D HYPHEN-MINUS).
Its syntax is:

<pre class="prod informative" nohighlight>
	--*( <<declaration-value>># )
</pre>

Issue: Mention semicolon upgrades.

A <<dashed-function>> can only be used where ''var()'' is allowed.

If a property contains one or more <<dashed-function>>s,
the entire property’s grammar must be assumed to be valid at parse time.
At computed-value time,
every <<dashed-function>> must be [=substitute a dashed function|substituted=]
before finally being checked against the property's grammar.

When a value is being computed,
substitution of ''var()'', ''env()'' and ''attr()''
must take place <em>before</em> <<dashed-function>> substitution.

Note: This means arguments passed to a custom function
never contain ''var()'', or similar functions.

A ''var()'' function within a [=local variable=],
or within the ''@function/result'' descriptor,
invokes [=locally substitute a var()|local substitution=],
rather than the computed-value based substitution
described in [[!css-variables]].

<div algorithm>
	To <dfn>substitute a dashed function</dfn> in a value,
		with |dashed function| being a <<dashed-function>>:

		1. Let |function| be the result of dereferencing
			the |dashed function|'s name as a [=tree-scoped reference=].
			If no such name exists, return failure.
		2. Let |dependency values| be an initially empty [=list=].
		3. For each |dependency| in |function|'s [=function dependency|dependencies=]:
			* Let |dependency value| be the value that would be substituted
				if a ''var()'' function had been specified explicitly
				at the end of |dashed function|'s argument list,
				with |dependency| as its only argument.
			* If that substitution would have made a containing declaration
				[=invalid at computed-value time=],
				set |dependency value| to the [=guaranteed-invalid value=].
			* Append the result of [=resolving an argument=] to |dependency values|,
				using |dependency value| as value,
				and |dependency| as parameter.
		4. [=Evaluate a custom function=],
			using |function|, |dashed function| and |dependency values|.
		5. If failure was returned, return failure.
		6. Otherwise,
			replace the <<dashed-function>> with the [=equivalent token sequence=]
			of the value resulting from the evaluation.
</div>

If [=substitute a dashed function=] fails,
and the substitution is taking place on a property's value,
then the declaration containing the <<dashed-function>> becomes
[=invalid at computed-value time=].

Evaluating Custom Functions {#evaluating-custom-functions}
----------------------------------------------------------

<div algorithm>
	To <dfn>evaluate a custom function</dfn>,
	with |function| being a [=custom function=],
	|dashed function| being the <<dashed-function>> invoking that |function|,
	and |dependency values| being a [=list=] of values.

	1. If the number of values in |dashed function|'s argument list
		is greater than the number of values in |function|'s [=function parameter|parameters=],
		return failure.
	2. For each value |parameter| in |function|'s [=function parameter|parameters=],
		let |argument| be the corresponding value in |dashed function|'s argument list
		at the same index:
		* If |argument| does not exist,
			set |argument| to the [=guaranteed-invalid value=].
		* Replace the value in |dashed function|'s argument list
			with the result of [=resolving an argument=],
			using |argument| as value,
			and |parameter| as parameter.
	3. Let |result| be the [=resolved local value=]
		of the '@function/result' descriptor,
		using |function|, |dashed function|, and |dependency values|.
	4. If |function| has a [=return type=],
		set |result| to the result of [=resolve a typed value|resolving a typed value=],
		using |result| as the value,
		and the [=syntax definition=] associated with the [=return type=] as the syntax.
	5. If |result| is the [=guaranteed-invalid value=],
		return failure.
	6. Otherwise,
		return |result|.
</div>

<div algorithm>
	To <dfn>resolve an argument</dfn>,
	with value |value|,
	and [=function parameter|parameter=] |parameter|:

	1. If |value| is not the [=guaranteed-invalid value=],
		and |parameter| has a [=parameter type|type=],
		set |value| to the result of [=resolve a typed value|resolving a typed value=]
		using |value| as the value,
		and the [=syntax definition=] associated with |parameter|'s type as the syntax.
		<span class=note>This step may cause |value| to become [=guaranteed-invalid value|guaranteed-invalid=].</span>
	2. If |value| is the [=guaranteed-invalid value=],
		and |parameter| has a [=default value=],
		set |value| to one of the following:
		<dl class="switch">
			:   If |parameter| has a [=parameter type|type=]
			::  The result of [=resolve a typed value|resolving a typed value=]
				using the |parameter|'s [=default value=] as the value,
				and the [=syntax definition=] associated with |parameter|'s type as the syntax.

			:   Otherwise
			::  The |parameter|'s [=default value=].
		</dl>
	3. Return |value|.

</div>

<div algorithm>
	To <dfn>resolve a typed value</dfn>,
	with value |value|,
	and [=syntax definition=] |syntax|:

	1. If |value| is the [=guaranteed-invalid value=],
		return |value|.
	2. <a href="https://drafts.css-houdini.org/css-properties-values-api-1/#calculation-of-computed-values">Compute</a>
		|value| as if it were the value associated with a [=registered custom property=]
		whose [=syntax definition=] is |syntax|.
	3. If this would lead to a declaration being [=invalid at computed-value time=],
		return the [=guaranteed-invalid value=].
	4. Otherwise, return that value.
</div>

Parameters and Locals {#parameters}
-----------------------------------

	The [=function parameters=] and [=function dependencies=] of a [=custom function=]
	are available for [=locally substitute a var()|local substitution=]
	as if they were declared as [=local variables=]
	at the start of the ''@function'' rule body.

	Note: A [=local variable=] with the same name
		as a [=function parameter=]/[=function dependency=] is allowed,
		but will make the parameter/dependency unreachable
		for [=locally substitute a var()|substitution=]

	A <dfn>local variable</dfn>
	is a custom property defined with the body of a [=custom function=].
	It is only visible within the function where it is defined.

<div algorithm>
	To <dfn>locally substitute a var()</dfn> within a value,
	with |function| being a [=custom function=],
	|dashed function| being the <<dashed-function>> invoking that |function|,
	and |dependency values| being a [=list=] of values:

	1. Let |substitution value| be one of the following options,
		depending on the [=custom property=] named in the first argument of the ''var()'' function:
		<dl class="switch">

			:   If the [=custom property=] name matches a [=local variable=] within |function|
			::  The [=resolved local value=] of that [=local variable=].

			:   Otherwise, if the [=custom property=] name matches a [=function parameter|parameter=] within |function|
			::  The corresponding argument value within the |dashed function|.

			:   Otherwise, if the [=custom property=] name matches a [=function dependency|dependency=] within |function|
			::  The corresponding value of that [=function dependency|dependency=]
				within |dependency values|.

			:   Otherwise
			::  The [=guaranteed-invalid value=].
		</dl>

	2. If |substitution value| is not the [=guaranteed-invalid value=],
		replace the ''var()'' function by that value.

	3. Otherwise, if the ''var()'' function has a fallback value as its second argument,
		replace the ''var()'' function by the [=resolved local value|locally resolved=] fallback value.

	4. Otherwise, return failure.
</div>

A <dfn>resolved local value</dfn> is the value of a [=local variable=] or [=descriptor=], except:

* Any ''var()'' functions are replaced by [=locally substitute a var()|local substitution=].
* Any ''env()'' or ''attr()'' functions are substituted normally.
* Any <<dashed-function>>s are replaced by [=substitute a dashed function|dashed function substitution=].

If any substitution algorithm returns failure,
then the [=resolved local value=] of a [=local variable=]
is the [=guaranteed-invalid value=].

Cycles {#cycles}
----------------

Issue: TODO

<!-- Big Text: execution

█████▌ █     █ █████▌  ███▌  █▌  █▌ █████▌ ████  ███▌  █    █▌
█▌      █   █  █▌     █▌  █▌ █▌  █▌   █▌    ▐▌  █▌  █▌ █▌   █▌
█▌       █ █   █▌     █▌     █▌  █▌   █▌    ▐▌  █▌  █▌ ██▌  █▌
████      █    ████   █▌     █▌  █▌   █▌    ▐▌  █▌  █▌ █▌▐█ █▌
█▌       █ █   █▌     █▌     █▌  █▌   █▌    ▐▌  █▌  █▌ █▌  ██▌
█▌      █   █  █▌     █▌  █▌ █▌  █▌   █▌    ▐▌  █▌  █▌ █▌   █▌
█████▌ █     █ █████▌  ███▌   ███▌    █▌   ████  ███▌  █▌   ▐▌
-->

Execution Model of Custom Functions {#execution-model}
======================================================

Like the rest of CSS,
[=custom functions=] adhere to a declarative model.

The [=local variable=] descriptors
and '@function/result' descriptor
can appear in any order,
and may be provided multiple times.
If this happens, then declarations appearing later win over earlier ones.

<div class='example'>
	<pre class='lang-css'>
	@function --mypi() {
	  result: 3;
	  result: 3.14;
	}
	</pre>
	The value of the '@function/result' descriptor of <code>--mypi</code>
	is <code>3.14</code>.
	</pre>
</div>

<div class='example'>
	<pre class='lang-css'>
	@function --circle-area(--r) {
	  result: calc(pi * var(--r2));
	  --r2: var(--r) * var(--r);
	}
	</pre>
	[=Local variable=] descriptors may appear before or after
	they are referenced.
	</pre>
</div>

Conditional Rules {#conditional-rules}
--------------------------------------

A [=conditional group rule=] that appears within a ''@function''
becomes a [=nested group rule=],
with the additional restriction
that only descriptors allowed within ''@function''
are allowed within the [=nested group rule=].

[=Conditional group rules=] within ''@function''
are <a href="https://drafts.csswg.org/css-conditional-3/#processing">processed</a> as normal,
acting as if the contents of the rule were present
at the [=conditional group rule=]'s location
when the condition is true,
or acting as if nothing exists at that location otherwise.

<div class='example'>
	<pre class='lang-css'>
	@function --suitable-font-size() {
		result: 16px;
		@media (width > 1000px) {
			result: 20px;
		}
	}
	</pre>
	The value of the '@function/result' descriptor
	is <code>20px</code> if the media query's condition is true,
	and <code>16px</code> otherwise.
	</pre>
</div>

<div class='example'>
	Note that due to the execution model,
	"early return" is not possible within a ''@function'':
	<pre class='lang-css'>
	@function --suitable-font-size() {
		@media (width > 1000px) {
			result: 20px;
		}
		result: 16px;
	}
	</pre>
	The value of the '@function/result' descriptor
	is always <code>16px</code> in the above example.
	</pre>
</div>

<div class='example'>
	[=Local variables=] are also valid within conditional rules:
	<pre class='lang-css'>
	@function --suitable-font-size() {
		--size: 16px;
		@media (width > 1000px) {
			--size: 20px;
		}
		result: var(--size);
	}
	</pre>
</div>

<!-- Big Text: cssom

 ███▌   ███▌   ███▌   ███▌  █     █
█▌  █▌ █▌  █▌ █▌  █▌ █▌  █▌ ██   ██
█▌     █▌     █▌     █▌  █▌ █▌█ █▐█
█▌      ███▌   ███▌  █▌  █▌ █▌ █ ▐█
█▌         █▌     █▌ █▌  █▌ █▌   ▐█
█▌  █▌ █▌  █▌ █▌  █▌ █▌  █▌ █▌   ▐█
 ███▌   ███▌   ███▌   ███▌  █▌   ▐█
-->

CSSOM {#cssom}
==============

The {{CSSFunctionRule}} interface represents a ''@function'' rule.

<pre class='idl' export>
[Exposed=Window]
interface CSSFunctionRule : CSSGroupingRule { };
</pre>

While declarations may be specified directly within a ''@function'' rule,
they are not represented as such in the CSSOM.
Instead, consecutive segments of declarations
appear as if wrapped in {{CSSNestedDeclarations}} rules.

Note: This also applies to the "leading" declarations in the ''@function'' rule,
	i.e those that do not follow another nested rule.

<div class='example'>
	<pre class='lang-css'>
	@function --bar() {
	  --x: 42;
	  result: var(--y);
	  @media (width > 1000px) {
	    /* ... */
	  }
	  --y: var(--x);
	}
	</pre>

	The above will appear in the CSSOM as:

	<pre class='lang-css'>
	@function --bar() {
	  /* CSSNestedDeclarations { */
	    --x: 42;
	    result: var(--y);
	  /* } */
	  @media (width > 1000px) {
	    /* ... */
	  }
	  /* CSSNestedDeclarations { */
	    --y: var(--x);
	  /* } */
	}
	</pre>
</div>

Issue: Should we indeed use {{CSSNestedDeclarations}} for this purpose?
	The <code>style</code> attribute of the {{CSSNestedDeclarations}} rule
	should probably not be a regular {{CSSStyleDeclaration}},
	since only custom properties
	and the '@function/result' descriptor
	are relevant.

<!-- Big Text: appendix

 ███▌  ████▌  ████▌  █████▌ █    █▌ ████▌  ████ █     █
▐█ ▐█  █▌  █▌ █▌  █▌ █▌     █▌   █▌ █▌  █▌  ▐▌   █   █ 
█▌  █▌ █▌  █▌ █▌  █▌ █▌     ██▌  █▌ █▌  █▌  ▐▌    █ █  
█▌  █▌ ████▌  ████▌  ████   █▌▐█ █▌ █▌  █▌  ▐▌     █   
█████▌ █▌     █▌     █▌     █▌  ██▌ █▌  █▌  ▐▌    █ █  
█▌  █▌ █▌     █▌     █▌     █▌   █▌ █▌  █▌  ▐▌   █   █ 
█▌  █▌ █▌     █▌     █████▌ █▌   ▐▌ ████▌  ████ █     █
-->

Appendix: The <<syntax>> Production {#syntax}
=============================================

The <<syntax>> production represents a [=syntax definition=],
which may be used to impose a type
on [=function parameters=],
[=function dependencies=],
or [=custom function=] return values.

<pre class="prod def" nohighlight>

<dfn><<type-name>></dfn> = angle | color | custom-ident | image | integer |
	length | length-percentage | number |
	percentage | resolution | string | time |
	url | transform-function
<dfn><<combinator>></dfn> = '|'
<dfn><<multiplier>></dfn> = [ '#' | '+' ]
<dfn><<syntax-component-name>></dfn> = '<' <<type-name>> '>' | <<custom-ident>>
<dfn><<syntax-component>></dfn> = <<syntax-component-name>> <<multiplier>>? |
	'<' transform-list '>'
<dfn><<syntax>></dfn> = '*' | <<syntax-component>> [ <<combinator>> <<syntax-component>> ]+

</pre>

A <<syntax-component>> consists of either a <<type-name>>,
which maps to one of the [=supported syntax component names=];
or a <<custom-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.

<div class='example'>
	<pre class='lang-css'>
	&lt;percentage&gt; | &lt;number&gt; | auto
	</pre>
	The above, when parsed as a <<syntax>>,
	would accept <<percentage>> values,
	<<number>> values,
	as well as the keyword <code>auto</code>.
</div>

<div class='example'>
	<pre class='lang-css'>
	red | &lt;color&gt;
	</pre>
	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>>.
</div>

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 <<multiplier>>.</span>

[=Whitespace=] is not allowed
between the angle bracket <<delim-token>>s (<code>&lt;</code> <code>&gt;</code>)
and the <<type-name>> they enclose,
nor is [=whitespace=] allowed to precede a <<multiplier>>.

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