CSS if() function

[tursunova]

こんにちは TAG-さん!

I'm requesting a TAG review of CSS if() function.

"The if() notation is an arbitrary substitution function that represents conditional values. Its argument consists of an ordered semi-colon–separated list of statements, each consisting of a condition followed by a colon followed by a value. An if() notation represents the value corresponding to the first condition in its argument list to be true; if no condition matches, then the if() notation represents an empty token stream." (From the spec.)

• Explainer¹: https://docs.google.com/document/d/1mbHBUR40jUBay7QZxgbjX7qixs5UZXkdL9tVwGvbmt0/edit?usp=sharing
• Specification: https://drafts.csswg.org/css-values-5/#if-notation
• WPT Tests:
• User research:
• Security and Privacy self-review²:
• GitHub repo: https://github.com/w3c/csswg-drafts/tree/main/css-values-5
• Primary contacts:
  • @tursunova, Google, working on the feature in Chromium.
• Organization/project driving the specification: Chromium
• Multi-stakeholder support³:
  • Chromium comments: Positive.
  • Mozilla comments: CSS if() function mozilla/standards-positions#1167
  • WebKit comments: CSS if() function WebKit/standards-positions#453
• Status/issue trackers for implementations⁴: https://issues.chromium.org/issues/346977961

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines:
• The group where the work on this specification is currently being done: CSSWG
• The group where standardization of this work is intended to be done (if different from the current group): CSSWG
• Major unresolved issues with or opposition to this specification:
• This work is being funded by:

[LeaVerou]

I'm biased because this was my proposal, but this is solving a host of huge author pain points, and together with style queries, can enable higher level custom properties which will make web component APIs a lot more fluent. The style() syntax is not ideal ergonomics, but it was chosen for consistency with style container queries and there are plans to expand it to regular value comparisons down the line.

The explainer examples could be better though. Comparison with color values is not the common case at all, and is rather hairy. The common case is probably a keyword valued custom property like --variant: success | warning | danger | neutral | primary and seeing how it can be used to set multiple other properties.

[torgo]

Hi @tursunova - Just noting that the explainer is in a google doc. It's not a blocker for our work, but when possible can you please move it to a markdown file, living wherever the spec is living? Thanks!

[xiaochengh]

Hi @tursunova - thank you for sending this our way. We touched on this in our TAG breakout today. Our initial view is positive. The main feedback point we have right now is that the explainer is thin and does not explain the user need. In particular, what the intended use cases are, and what the alternative solutions and the status quo are. We have a what is an explainer document which talks about the motivation for explainers and what we usually like to see in one. An important part of explainers is to start with user needs. Can you please revise the explainer accordingly?