Overview.bs

<pre class="metadata">
Title: CSS Conditional Rules Module Level 5
Group: csswg
Shortname: css-conditional
Level: 5
Status: FPWD
Prepare for TR: yes
Date: 2021-12-21
!Delta Spec: yes
Work Status: Exploring
ED: https://drafts.csswg.org/css-conditional-5/
TR: https://www.w3.org/TR/css-conditional-5/
Editor: L. David Baron, Mozilla https://www.mozilla.org/, https://dbaron.org/, w3cid 15393
Editor: Elika J. Etemad / fantasai, Apple, http://fantasai.inkedblade.net/contact, w3cid 35400
Editor: Chris Lilley, W3C, https://svgees.us/, w3cid 1438
Abstract: This module contains the features of CSS
	for conditional processing of parts of style sheets,
	based on capabilities of the processor or the environment
	the style sheet is being applied in.
	It includes and extends the functionality of CSS Conditional 4 [[!css-conditional-4]],
	adding the generalized conditional rule ''@when''
	and the chained conditional rule ''@else'',
	as well as introducing font processing queries
	to the [=supports query=] syntax used in ''@supports'' rules.
Default Highlight: css
</pre>

<pre class="link-defaults">
	spec: css-conditional-3
		type: dfn; text: conditional group rule
</pre>

<h2 id="introduction">
Introduction</h2>

	ISSUE: This is currently an early draft of the things that are <em>new</em> in level 5.
	The features in Level 3 and Level 4 are still defined
	in [[css-conditional-3]] and [[css-conditional-4]]
	and have not yet been copied here.

	CSS Conditional Level 5 extends
	the ''@supports'' rule and [=supports query=] syntax
	to allow testing for supported font technologies.

	It also adds an ''@when'' rule,
	which generalizes the concept of a conditional rule.
	Anything that can be expressed in an existing conditional rule
	can be expressed in ''@when''
	by wrapping it in an appropriate function
	to declare what kind of condition it is.
	This allow authors to easily combine multiple types of queries,
	such as media queries and supports queries,
	in a single boolean expression.
	Without this,
	authors must rely on nesting separate conditional rules,
	which is harder to read and write,
	presupposes the conditions are to be conjoined with the “and” boolean relation
	(with no easy way to indicate anything else),
	and restricts their utility in the proposed [=conditional rule chains=].

	It also adds ''@else'' rules,
	which immediately follow other conditional rules
	and automatically qualify their conditions
	as the inverse of the immediately preceding rule’s conditions,
	such that only the first matching rule in a [=conditional rule chain=]
	is applied.

<h2 id="at-supports-ext">
Extensions to the ''@supports'' rule</h2>

	This level of the specification extends the <<supports-feature>> syntax as follows:

	<pre class="prod def" nohighlight>
		<dfn>&lt;supports-feature></dfn> = <<supports-selector-fn>> | <<supports-font-tech-fn>>
		                    | <<supports-font-format-fn>> | <<supports-decl>>
		<dfn>&lt;supports-font-tech-fn></dfn> = font-tech( <<font-tech>> )
		<dfn>&lt;supports-font-format-fn></dfn> = font-format( <<font-format>> )
	</pre>

	: <<supports-font-tech-fn>>
	::
		The result is true if the UA
		<a href="#dfn-support-font-tech">supports the font tech</a>
		provided as an argument to the function.

	: <<supports-font-format-fn>>
	::
		The result is true if the UA
		<a href="#dfn-support-font-format">supports the font format</a>
		provided as an argument to the function.

<h3 id="support-definition-ext">
Extensions to the definition of support</h3>

	A CSS processor is considered to
	<dfn export for=CSS id="dfn-support-font-tech">support a font tech</dfn>
	when it is capable of utilizing the specified [[css-fonts-4#font-tech-definitions]]
	in layout and rendering.

	A CSS processor is considered to
	<dfn export for=CSS id="dfn-support-font-format">support a font format</dfn>
	when it is capable of utilizing the specified [[css-fonts-4#font-format-definitions]]
	in layout and rendering,
	and this format is not specified as a <<string>>.

<h2 id="when-rule">
Generalized Conditional Rules: the ''@when'' rule</h2>

	The <dfn>@when</dfn> at-rule is a [=conditional group rule=]
	that generalizes the individual [=conditional group rules=]
	such as ''@media'' and ''@supports''.
	It is defined as:

	<pre class=prod>
		@when <<boolean-condition>> {
		  <<rule-list>>
		}
	</pre>

	Where <<boolean-condition>> is a boolean algebra a la [[mediaqueries-4#mq-syntax]],
	but with ''media()'' and ''supports()'' functions as leaves.

	Issue: Define "boolean algebra, with X as leaves" in a generic way in Conditional,
	so all the conditional rules can reference it directly,
	rather than having to redefine boolean algebra on their own.

	The ''media()'' and ''supports()'' functions are defined as:

	<pre class=prod>
	<dfn>media()</dfn> = media( [ <<mf-plain>> | <<mf-boolean>> | <<mf-range>> ] )
	<dfn>supports()</dfn> = supports( <<declaration>> )
	</pre>

	A ''media()'' or ''supports()'' function is associated the boolean result
	that its contained condition is associated with.

<h2 id="else-rule">
Chained Conditionals: the ''@else'' rule</h2>

	Usually, [=conditional group rules=] are independent;
	each one has a separate condition
	evaluated without direct reference to any other rule,
	and decides whether or not to apply its contained rules
	based solely on its condition.

	This is fine for simple conditions,
	but makes it difficult to write a collection of conditionals
	that are meant to be mutually exclusive:
	authors have to very carefully craft their conditions
	to not activate when the other rules are meant to,
	and make sure the collection of conditionals
	don't accidentally <em>all</em> exclude some situation
	which is then left unstyled.

	The <dfn>@else</dfn> rule is a [=conditional group rule=]
	used to form [=conditional rule chains=],
	which associate multiple [=conditional rules=]
	and guarantee that only the first one that matches
	will evaluate its condition as true.
	It is defined as:

	<pre class=prod>
		@else <<boolean-condition>>? {
			<<rule-list>>
		}
	</pre>

	''@else'' is interpreted identically to ''@when''.
	If its <<boolean-condition>> is omitted,
	it's treated as having a condition that's always true.

	A <dfn export>conditional rule chain</dfn> is
	a series of consecutive [=conditional group rules=],
	starting with a [=conditional group rule=] other than ''@else'',
	followed by zero or more ''@else'' rules.
	There cannot be anything between the successive [=conditional group rules=]
	other than whitespace and/or comments;
	any other token “breaks” the chain.

	Issue: Should we require that only the last ''@else'' in a chain can have an omitted condition?
	It's not uncommon for me, when debugging code,
	to short-circuit an if-else chain by setting one of them to "true";
	I presume that would be similarly useful in CSS?
	It's still pretty easy to see you've done something wrong if you omit the condition accidentally.

	Within a [=conditional rule chain=],
	the conditions of each [=conditional group rule=] are evaluated in order.
	If one of them is true,
	the conditions of all <em>following</em> [=conditional group rules=] in the chain
	evaluate to false,
	regardless of their stated condition.

	An ''@else'' rule that is not part of a [=conditional rule chain=]
	is invalid and must be ignored.

	<div class=example>
		For example, here's a (somewhat silly) conditional chain:

		<pre class="lang-css">
			@when media(width >= 400px) and media(pointer: fine) and supports(display: flex) {
			  /* A */
			} @else supports(caret-color: pink) and supports(background: double-rainbow()) {
			  /* B */
			} @else {
			  /* C */
			}
		</pre>

		Exactly one of the preceding rules will be chosen,
		even though the second rule
		doesn't exclude large widths, fine points, or flexbox support,
		and the last rule
		doesn't specify anything at all.

		To achieve the same result without [=conditional rule chains=],
		you'd need to write:

		<pre class="lang-css">
			@media (width >= 400px) and (pointer: fine) {
			  @supports (display: flex) {
			    /* A */
			  }
			  @supports not (display: flex) {
			    @supports (caret-color: pink) and (background: double-rainbow()) {
			      /* B */
			    }
			    @supports not ((caret-color: pink) and (background: double-rainbow())) {
			      /* C */
			    }
			  }
			}
			@media not ((width >= 400px) and (pointer: fine)) {
			  @supports (caret-color: pink) and (background: double-rainbow()) {
			    /* B */
			  }
			  @supports not ((caret-color: pink) and (background: double-rainbow())) {
			    /* C */
			  }
			}
		</pre>

		This is simultaneously hard to read,
		requires significant duplication of both conditions and contents,
		and is <em>very</em> difficult to write correctly.
		<!-- (I wrote it wrong <em>twice</em> while producing this example.) -->
		If the conditions got any more complicated
		(which is not unusual in real-world content),
		the example would get <em>significantly</em> worse.
	</div>

	<div class="example">
		In this example, three different color font technologies
		are tested, in order of preference,
		plus a monochrome fallback.
		The most capable, COLRv1, supports both gradients and font variations;
		the next best choice, SVG, supports gradients
		while the least capable, COLRv0, supports flat color fill only.

		The fallback has no test condition,
		so will always be chosen unless one of the earlier conditions succeeds.

		<pre class="lang-css">
			@when font-tech(color-COLRv1) and font-tech(variations) {
			  @font-face { font-family: icons; src: url(icons-gradient-var.woff2); }
			}
			@else font-tech(color-SVG) {
			  @font-face { font-family: icons; src: url(icons-gradient.woff2); }
			}
			@else font-tech(color-COLRv0) {
			  @font-face { font-family: icons; src: url(icons-flat.woff2); }
			}
			@else {
			  @font-face { font-family: icons; src: url(icons-fallback.woff2); }
			}
		</pre>

		Notice that in this example,
		the variable color font is only downloaded
		if COLRv1 is supported
		and font variations are also supported.

		Notice too that only one of the available options will be downloaded;
		this would not be the case without ''@when'' and ''@else'',
		as the next example shows.
	</div>

	<div class="example">
		In this example,
		although it appears that the fallback will not be used
		if COLRv1 is supported,
		in fact both fonts will be downloaded,
		which wastes bandwidth if it is not used.

		The fallback might still be used for some characters;
		for example, if the color font supports only Latin,
		while the fallback supports Latin and Greek.

		<pre class="lang-css">
			@font-face { font-family: icons; src: url(icons-fallback.woff2);
			@supports font-tech(color-COLRv1) {
			  @font-face { font-family: icons; src: url(icons-gradient-var.woff2); }
			}
		</pre>
	</div>

<h2 class=no-num id="security">Security Considerations</h2>

	No security issues have been raised against this document

<h2 class=no-num id="privacy">Privacy Considerations</h2>

	<!-- COPY FROM L3 when importing the rest of the spec -->

	The ''font-tech()'' and ''font-format()'' functions
	may provide information about the user's software
	such as its version
	and whether it is running with non-default settings that enable or disable certain features.

	This information can also be determined through other APIs.
	However, the features in this specification are one of the ways this information
	is exposed on the Web.

	This information can also, in aggregate, be used to improve the accuracy of
	<a href="https://www.w3.org/2001/tag/doc/unsanctioned-tracking/">fingerprinting</a> of the user.

<h2 class=no-num id="acknowledgments">Acknowledgments</h2>

	The ''@when'' and ''@else'' rules are based on a proposal by Tab Atkins.

<h2 id='changes' class='no-num'>
Changes</h2>

<h3 id="changes-from-L4" class="no-num">
Additions since Level 4</h3>

	<ul>
		<li>Added ''@when'' and ''@else''.
		<li>Extended [=supports queries=] to express font capabilities
			via ''font-tech()'' and ''font-format()''.
	</ul>