w3c
[css-values-5] What is the MVP for inline conditionals on custom properties?
Edit: Resolved to pursue this! 🎉
There are several issues across this repo proposing some kind of inline conditional function. Here is a sample:
- https://github.com/w3c/csswg-drafts/issues/5624
- https://github.com/w3c/csswg-drafts/issues/5009
- https://github.com/w3c/csswg-drafts/issues/6638
- https://github.com/w3c/csswg-drafts/issues/4731
- https://github.com/w3c/csswg-drafts/issues/3455
Yet, this is another case where progress has stalled because we’re trying to flesh out a much more general and powerful feature, which involves a significant amount of design & implementation effort. Meanwhile, this major author pain point remains unsolved, and authors have to resort to HTML attributes instead (as explained in #5624).
The current workarounds are:
- Using a 0/1 switch and linear interpolation:
calc(var(--test) * var(--if-true) + (1 - var(--test)) * var(--if-false)) - "Space toggle": Using presence/absence and
var(--test, var(--if-false)) - Style container queries: these are great, but only work on descendants.
- Cyclic Dependency Space Toggles
However, there is no workaround for transforming arbitrary keywords to arbitrary values, even simple values. E.g. custom properties like these are impossible to implement (examples inspired from the presentational attributes found in Shoelace, one of the most popular web component libraries, but similar use cases can be found in almost any design system and/or WC library):
-
--variant: auto | primary | success | neutral | warning | danger -
--effect: none | pulse -
--button-style: fill | outline -
--shape: rect | pill -
--avatar-shape: square | rounded | circle -
--size: small | medium | large -
--suffix: none | caret` -
--popup-placement: [top | right | bottom | left] [start | end]? -
--popup-arrow-placement: center | start | end
What if we could come up with an MVP that could be implemented fast and extended later?
We could scope it down quite a lot and still have something that addresses the most pressing author pain points. Some example restrictions we could start with:
- Only
style( <style-query> )conditionals - Only custom properties
- If it helps, the value space could be restricted too, even as much as single tokens
- If it helps, it could even be something that’s only allowed in custom property values
Edit (June 10th, 2024):
I had a chat with @andruud a few days ago, and he said that this proposed design would be fairly easy to implement.
Grammar:
<if()> = if( <container-query>, [<declaration-value>]{1, 2} )
- Links:
- Values can be nested to produce multiple branches
- If a third argument is not provided, it becomes equivalent to an empty token stream
I did not discuss this but a nice DX improvement could be this grammar instead:
<if()> = if(
[ <container-query>, [<declaration-value>]{2} ]#{0, },
<container-query>, [<declaration-value>]{1, 2}
)
which would allow for multiple conditions more easily. Compare:
Grammar 1:
background-color: if(
style(--variant: success), var(--color-success-60),
if(style(--variant: warning), var(--color-warning-60),
if(style(--variant: danger), var(--color-danger-60),
if(style(--variant: primary), var(--color-primary))
),
)
);
Grammar 2:
background-color: if(
style(--variant: success), var(--color-success-60),
style(--variant: warning), var(--color-warning-60),
style(--variant: danger), var(--color-danger-60),
style(--variant: primary), var(--color-primary)
);
Behavior: Any invalid value would make the property IACVT.
Does it cover enough use cases? I think so. Ideally, you'd want a mechanism to fallback to whatever value the declaration would have normally if nothing matches, instead of IACVT, but that’s much harder to implement.
Implementors, would this make it tractable? If not, what would?
Style container queries: these are great, but only work on descendants.
when i first discovered style queries, i admit i had intuitively tried to do something like this:
@container style(--variant: large) {
& {
/* style the container itself */
}
}
it seems a way to select the container that @container style() matches would be a nice stepping stone but i have nowhere near enough context/history to know if that is doable.
or maybe enabling style queries as part of the @scope api?
@scope style(--variant: large) {
:scope {}
}
I had a chat with @andruud a few days ago, and he said that this proposed design would be fairly easy to implement.
Edit: updated first post
Yeah, at least if we choose the path forwards carefully, it should be easy. That carefully chosen path could be something like:
- When you see an
if()in a declaration's value, you get the "assumed valid at parse time" behavior we currently get when there's avar()orenv()in the value.- Substituting an
if()then mostly just becomes an advancedvar()substitution, with some conditionals built in to it.
- Substituting an
- The
if()function can evaluate exactly what style CQs can evaluate, and nothing else (for now).- This means only custom properties are supported in practice. (Despite style() currently being specified with support for standard properties, implementations never picked it up.)
Of course we'll need to deal with cycles. e.g.:
div {
--x: if(style(--y: 1), 0, 1);
--y: var(--x);
}
But we should be well equipped to handle that.
So if the CSSWG determines that this is worthwhile, it should be quite doable overall.
I suppose it's worth thinking about custom functions here as well, since they also kind of provide "inline" conditionals. It might not be ergonomic to use for the use-cases you have in mind, though.
It would seem a bit strange to me if display: if(--x, nonsense, bullshit) is considered valid at parse time, since we know that both possibilities are invalid.
It would seem a bit strange to me if
display: if(--x, nonsense, bullshit)is considered valid at parse time, since we know that both possibilities are invalid.
I’m fine to make it invalid at parse time, but it seems like a lot of work for an edge case. Especially given there might be multiple conditionals for a single property value, so it's a combinatorial explosion to tell if any of them would result in a valid value.
Substituting an
if()then mostly just becomes an advancedvar()substitution, with some conditionals built in to it.The
if()function can evaluate exactly what style CQs can evaluate, and nothing else (for now).
- This means only custom properties are supported in practice. (Despite style() currently being specified with support for standard properties, implementations never picked it up.)
Yup. How hard would it be to support other queries beyond style()? E.g. size queries, supports(), media()?
(style() does address the vast majority of use cases, but if any of these are easy, we may as well support them too.)
I don't see why we couldn't do supports() and media(), but size queries would cause cycles with layout that are hard/impossible to even detect. (That's why we needed the restrictions we currently have for size CQs in the first place.)
I don't see why we couldn't do
supports()andmedia(), but size queries would cause cycles with layout that are hard/impossible to even detect. (That's why we needed the restrictions we currently have for size CQs in the first place.)
Fair. So we’ll need a distinct token and not <container-query>.
@tabatkins is there any easy way to do that without copying all the logic for and/or/not?
A few more workarounds authors can use right now:
- Conditions for CSS Variables — mentioned in the issue, but I want to bring attention to the fact that I wrote this post in October 2016 — right after the custom properties appeared in all major browsers (except from Edge, where it appeared a year later). Author interest for conditions like this was present throughout the years ever since, for example, see DRY Switching with CSS Variables by Ana Tudor from 2018
- “CSS-Only Type Grinding” by Jane Ori — a very (I repeat, very) convoluted but working (including in Firefox Nightly) way of using registered custom properties to achieve selecting some value based on an ident.
- Before I came up with “Cyclic Dependency Space Toggles”, I did a number of experiments (some of which I think I saw before in some ways, so authors were already reaching for these as possible workarounds for the absence of conditions):
- https://codepen.io/kizu/pen/mdQyNqq — accessing specific paused keyframes by a
<number>custom property. - https://codepen.io/kizu/pen/YzRXXXL — using named paused animations and accessing them as a
<ident>custom property.
- https://codepen.io/kizu/pen/mdQyNqq — accessing specific paused keyframes by a
- Outside of using
1or0values it is possible to work around the absence of conditions for<length>by using rather cumbersome but working calculations as a way to compare lengths: https://codepen.io/kizu/pen/WNBEKvW - Not yet working in Firefox due to a bug, but a possible way to conditionally detect if some custom property is not initial on the element itself: https://codepen.io/kizu/pen/zYQdamG — via an animation that applies space toggles for the default state.
I recommend going to the linked articles and codepens to witness the hacky CSS that is currently required to achieve those conditionals.
Given how often authors reach out to things like space toggles or come up with more and more convoluted ways to achieve conditions for different use cases (Is a custom property defined? Is value A is smaller than B? Are those two conditions true? Etc.), we really need at least some way to have these kinds of conditions.
Ideally, I'd want to have both inline conditions, but also an at-rule-level ones, but even if we will resolve only on inline conditions it will improve the lives of authors tremendously.
is there any easy way to do that without copying all the logic for and/or/not?
Unfortunately not, you gotta just write out the full grammar. It's mostly copy-pasting tho.
there might be multiple conditionals for a single property value
Ah, I was thinking of a <whole-value>. If it's not, then it makes more sense to accept everything, yes.
If we go with grammar 2 (which I think is the better grammar), I'd note that most programming languages don't call that construct "if", but rather "switch", "select", "case", "cond"… I'd suggest going with "switch", since that's what it's called in JS.
The CSS Working Group just discussed [css-values?] What is the MVP for inline conditionals on custom properties?.
RESOLVED: Add if() to css-values-5
The full IRC log of that discussion
<astearns> zakim, open queue<Zakim> ok, astearns, the speaker queue is open
<fantasai> leaverou: Motivating use cases
<fantasai> leaverou: right now web components libraries introduce tons of presentational attributes
<fantasai> leaverou: because custom properties include parts of values
<fantasai> leaverou: you can transform numeric values using calc() but keywords not possible
<fantasai> leaverou: Canonical example is changing background-color based on a `--variant` property
<fantasai> leaverou: These are examples for why I started shoelace library now called WebAwesome
<fantasai> leaverou: [lists many examples of utility classes]
<fantasai> leaverou: Style queries get us a lot of the way there, but because they only work on descendants
<fantasai> leaverou: that doesn't let us get all the way there
<fantasai> leaverou: so these remain presentational attributes
<fantasai> leaverou: but needing to branch on a condition is very common in CSS
<fantasai> leaverou: several issues last few years about how can we do this
<fantasai> leaverou: either as a block conditional
<fantasai> leaverou: or inline
<fantasai> leaverou: there are some extremely hacky workarounds that authors use
<fantasai> leaverou: e.g. stting custom property to an empty token string so it gets a value or falls back. Very very hacky things
<fantasai> leaverou: Despite huge demand there's no progress
<fantasai> leaverou: I opened this issue to explore what is still useful, but still easy for implementers
<fantasai> leaverou: Anders said if we re-use the conditional from container queries, that let's you compare values
<fantasai> leaverou: and even media and supports queries
<fantasai> leaverou: re-use that part and then declaration values chosen based on conditional
<fantasai> leaverou: said it was pretty easy
<fantasai> leaverou: For many of these use cases, instead of having one or two values, you could have a series of subsequent conditionals
<fantasai> leaverou: that's nice to hvae
<fantasai> leaverou: but main thing is single test, can always nest
<fantasai> leaverou: ideally we want a block conditional that applies when matches
<fantasai> leaverou: but that seems to be hard, so let's do inline first
<fantasai> leaverou: because we need it anyway
<fantasai> leaverou: if it can be implemented quickly, would be an easy win
<TabAtkins> q+
<kizu> q+
<fantasai> TabAtkins: This sounds good.
<astearns> ack TabAtkins
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/5009#issuecomment-626072319
<fantasai> TabAtkins: going back to previous thread, this comments lists out 3 variants of conditionals
<fantasai> TabAtkins: This is a variant of item 3
<fantasai> TabAtkins: one important part is these shouldn't be a boolean (true/false), it should be multi-valued so you can provide more than one test
<fantasai> TabAtkins: in simplest case that's true or false, just omit last test
<leaverou2> q+
<leaverou2> q++
<fantasai> TabAtkins: but I want to make sure you can sequence tests
<leaverou2> qq+
<leaverou2> q-
<fantasai> leaverou: it's the second grammar
<emilio> q- +
<fantasai> TabAtkins: sgtm
<astearns> ack fantasai
<astearns> ack leaverou
<TabAtkins> fantasai: I think that the IACVT behavior is not amazing
<TabAtkins> fantasai: so i dont' want us to have authors rely on it all the time bc there's no alt
<leaverou2> q+
<TabAtkins> fantasai: to the extent taht people want to switch on a custom prop, can't we do that with some sort of conditional...
<TabAtkins> fantasai: if you just switch basics based on conditionals you can avoid cycles easily that way
<fantasai> leaverou: Would be useful, but this is orthogonal
<TabAtkins> leaverou: a block conditional *would* be useful, but it's orthogonal
<TabAtkins> leaverou2: same as in JS
<TabAtkins> fantasai: not orthogonal from ux perspective. whether someone uses block or inline conditional is somewhat based on availability
<TabAtkins> fantasai: if you have both you'll use both, but if you have only one you'll shoehorn
<TabAtkins> fantasai: i think we should do both if we can
<fantasai> TabAtkins: isnt' the block version just style queries and media queries?
<fantasai> leaverou: Style queries only work on descendants
<TabAtkins> TabAtkins: getting a style query block *on the element* *requires* IACVT
<andruud> q+
<fantasai> fantasai: Shouldn't be a problem if you have standard properties set based on custom properties
<fantasai> TabAtkins: If you restrit it only to standard properties, that's substantially restrictive
<fantasai> TabAtkins: a lot of cases will want to set more variables
<miriam> q+
<fantasai> TabAtkins: Those will then need to use inline version, because that's a requirement of inline
<fantasai> s/because/which uses IACVT because/
<fantasai> TabAtkins: IACVT triggers if you write something wrong
<astearns> ack kizu
<fantasai> kizu: Wanted to show some worse things
<fantasai> kizu: In October 2016, I was using custom properties to switch between values using calculations
<fantasai> kizu: today you can use comparisons with calculations, if length is bigger or smaller use different value -- only for lengths
<fantasai> kizu: ?? made it possible to use values with custom properties
<fantasai> kizu: using type griding
<fantasai> kizu: a very long chain of fallbacks to registered custom property
<fantasai> kizu: and that let's you get any value back
<miriam> s/??/Jane Ori/
<kizu> https://github.com/w3c/csswg-drafts/issues/10064#issuecomment-2161742249
<fantasai> kizu: The code is very complicated
<fantasai> kizu: authors can now do this
<astearns> q?
<fantasai> kizu: recent article where using layers and [missed]
<fantasai> kizu: taking advantage of revert-layer
<fantasai> kizu: The need for this from authors is very high
<leaverou2> fantasai note that all the workarounds involve var(). So all workarounds ALREADY invoke IACVT. This is just about making the API and ergonomics infinitely nicer
<fantasai> kizu: Also wanted to mention, how could we use registered custom properties to avoid some issues with IACVT
<fantasai> kizu: For those we know what types they can accept, what they can return, might make it more simple
<astearns> ack leaverou2
<astearns> ack leaverou
<fantasai> leaverou2, Yeah. My point is I don't want authors to need to use this MORE because it'll be so much easier, simply because don't have a better alternative
<fantasai> fantasai: I don't think we should be trying to encourage authors to use a bad behavior, rather than trying to make something that works better with the cascade
<fantasai> fantasai: Like we should try to make it work the right way rather than settling for IACVT
<astearns> ack andruud
<fantasai> kizu: Using animations to do this is worse
<fantasai> andruud: For block version, if your conditional contains a registered custom property and you try to style the font size with em units, you'll get a cycle
<astearns> ack miriam
<fantasai> andruud: so we'll still run into cycle problems with block version
<fantasai> miriam: Do those cycles make th whole thing impossible, or do they just mean font-size is invalid and we do the condition
<leaverou2> ;?
<fantasai> andruud: for the block conditional?
<leaverou2> q?
<leaverou2> q+
<fantasai> andruud: I guess we could handle those cases 1 by 1
<fantasai> TabAtkins: dependencies will crop up over time, so hard to block ad-hoc
<astearns> ack leaverou
<fantasai> leaverou2: The block version will be inherently limited, because some values will only make sense on a single property
<fantasai> leaverou2: e.g. em/auto/normal
<fantasai> leaverou2: even if we have block version, still need inline version
<fantasai> leaverou2: Also you can assign conditions to a variable and then use that variable in a function, including media test
<fantasai> leaverou2: so handle breakpoints more easily
<fantasai> astearns: Lots of acknowledgement that this is important to work on
<fantasai> astearns: but also some concern about increasing the IACVT behavior on the web
<fantasai> TabAtkins: I don't believe we can solve anything in this space without IACVT
<fantasai> TabAtkins: so unless we can avoid cycles with some new idea, then we need to move forward with IACVT
<TabAtkins> fantasai: i don't object
<TabAtkins> fantasai: lea, can you outline the proposed syntax?
<leaverou2> border-radius: if(style(--button-shape: pill), infinity);
<ydaniv> Is this something that could later be speced to replace IACVT into a proper behavior?
<leaverou2> Longer example: background-color: if(
<leaverou2> style(--variant: success), var(--color-success-60),
<leaverou2> style(--variant: warning), var(--color-warning-60),
<leaverou2> style(--variant: danger), var(--color-danger-60),
<leaverou2> style(--variant: primary), var(--color-primary)
<leaverou2> );
<fantasai> fantasai: I think it would be better if the comma wasn't used both to separate conditional and value, as well as separate sets of conditionals
<TabAtkins> use a colon!
<florian> q+
<fantasai> leaverou2: seems reasonable. Could maybe use a slash
<bkardell_> +1 TabAtkins
<astearns> ack florian
<fantasai> leaverou2: could even use a ? and be more like JS
<lwarlow> q+
<TabAtkins> suggest we take that syntax question to the issue
<fantasai> florian: suggest using switch() for multiple cases, like JS
<fantasai> leaverou2: The conditionals here chain like else-if
<fantasai> leaverou2: but this expands to ranges, etc.
<TabAtkins> yeah, this is an if/elif/elif/else chain
<astearns> ack lwarlow
<fantasai> s/chain like else-if/chain like else-if, you have to provide the conditional each time/
<fantasai> lwarlow: agree with not using comma for both places
<fantasai> lwarlow: slash would read better
<leaverou2> Just noticed all examples above have no else value. This is another example: `border-radius: if(style(--button-shape: pill), infinity, .2em);`
<fantasai> PROPOSED: Add this to css-values-5
<lwarlow> +1
<fantasai> astearns: any objections?
<leaverou2> +1
<bkardell_> https://www.irccloud.com/pastebin/nrStwApc/
<fantasai> RESOVLED: Add if() to css-values-5
The syntax as described makes it slightly impossible to say "else be IACVT" in some cases. (For these examples, I'm gonna assume we use : between the condition and value, btw.)
if(style(...): foo, bar) could be a single value foo, bar (and IACVT if false), or two values (foo if true, bar if false). This does have a defined parse - it's always two values. But if you wanted it to be one value, and then IACVT for false, you can't write that.
(This ambiguity doesn't occur if there are multiple chained conditions. if(style(...): foo; style(...): bar, baz) unambiguously doesn't have a default case; the bar, baz is the whole value for the second condition. It's only in the single-condition case that we haven't yet gotten unambiguous information about what the separator is.)
So I think we'll need an explicit syntax for saying "no default condition". You don't usually need it, but occasionally you will, and it might make some cases clear even when it's not strictly required. Like, if(style(...): foo, bar; no-value) or something. (Special keyword, allowed only as the whole value of the final argument, always matches but resolves to the guaranteed-invalid value.)
@tabatkins Why not simply make the last argument mandatory and allow empty values (just like var())?
Compare:
Option 1 (mandatory last argument that can be empty):
border-radius: if(style(--button-shape: pill), infinity, );
Option 2 (default: clause):
border-radius: if(style(--button-shape: pill), infinity / default: );
One advantage of having a special value (e.g. revert-declaration?) is that perhaps we can improve on the IACVT behavior by keeping other declarations around when that is encountered (but probably we can't).
If that’s not an option, I'd rather introduce a different separator than a whole keyword. I’m generally all for prioritizing readability, but readability is a balance: too concise and it doesn't make sense, too wordy and you have to wade through the clutter to understand it. With something that I expect will be used all over the place, conciseness matters quite a lot.
hy not simply make the last argument mandatory and allow empty values (just like var())?
That's possible, I just find it less clear to read. I don't really like how var() allowed it.
One advantage of having a special value (e.g. revert-declaration?) is that perhaps we can improve on the IACVT behavior by keeping other declarations around when that is encountered (but probably we can't).
I'm not trying to solve any feature lack, just a syntax lack around the existing features.
If that’s not an option, I'd rather introduce a different separator than a whole keyword. I’m generally all for prioritizing readability, but readability is a balance: too concise and it doesn't make sense, too wordy and you have to wade through the clutter to understand it. With something that I expect will be used all over the place, conciseness matters quite a lot.
We can't invent infinite separators. ^_^ But also, this is something that is rarely needed - like I said, the only case that requires it is when you want to supply a single test, with a positive value containing a comma, and no negative value. If you do want to use it for clarity in other cases, I think it's perfectly readable. For example:
background-color: if(
style(--variant: success): var(--color-success-60),
style(--variant: warning): var(--color-warning-60),
style(--variant: danger): var(--color-danger-60),
style(--variant: primary): var(--color-primary),
no-value
);
If that’s not an option, I'd rather introduce a different separator than a whole keyword.
Actually, let me state this better: this isn't about the separator. The issue is just that the grammar doesn't allow an empty option (and I don't think it should), so there's one particular case you can't express.
@tabatkins Actually, if we don’t use a custom character for separating the condition from the values like the original proposal, this becomes a non-problem. By the time you get to the first value, you know what your separator is, so there’s no ambiguity in if(style(...), foo, bar).
@fantasai you raised the issue of using a distinct character for separating the condition from the value(s), and I agree this would be nice. However, given the ambiguity this introduces, are you ok with going with a comma/semicolon for both to avoid having to introduce weird new keywords like no-value?
@LeaVerou I don't understand the problem.
If we use a different character to separate the condition from the values (say ? or :), then if(style(...) ? foo, bar) is ambiguous: is foo, bar as a whole the if true value, or is the comma a separator? This is because the first time we encounter the separator is when it separates the if true value from the if false value, and we don’t know when to stop parsing these, so we rely on the separator. However, the grammar for conditions is far more restricted, so we know when we’ve stopped parsing the condition, and the character that follows (; or ,) is the function separator, so if(style(...), foo, bar) has no such ambiguity.
The other ways to address it are to make the last argument mandatory and either:
- Allow empty values there (
if(style(...) ? foo)) - Introduce a keyword to represent an empty token stream (
if(style(...) ? foo, no-value))
That said, you may want to use an empty value for the if true condition, so these may be orthogonal (though you can always negate the condition, so that’s just syntactic sugar). We could discuss what that value would look like in #10441 .
I hate to be that guy, but I think the name of the function itself could be improved, instead of just "if"? For example, SQL has the IIF() function which works like this IIF(expression, value-if-true, value-if-false). In general "if" means branching but here we are not branching, we are "selecting" a value depending on an expression, correct?
By the time you get to the first value, you know what your separator is, so there’s no ambiguity in if(style(...), foo, bar).
urgh, i really wouldn't want if(style(...); foo, bar; ...). Gives me aesthetic icks.
In general "if" means branching but here we are not branching, we are "selecting" a value depending on an expression, correct?
This is equivalent to an if/elif/elif/else chain. Whether an if is a statement (just executing code) or an expression (evaluating to some value) varies between languages. In the context where this exists in CSS, it's clearly an expression-level thing; the equivalent of an if "statement" would be an @if rule
@LeaVerou I think it isn't more ambiguous than font-family: random-item(serif, sans-serif, monospace), as mentioned https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1999706240, which needs some spec edits (unless they have already happened), but then it's well-defined?
One advantage of having a special value (e.g.
revert-declaration?) is that perhaps we can improve on the IACVT behavior by keeping other declarations around when that is encountered
Such a thing is being discussed in #5319
If we use a different character to separate the condition from the values (say ? or :), then if(style(...) ? foo, bar) is ambiguous:
It's not ambiguous - as I said in my earlier comment, it has a defined parse. Absent any semicolons, commas are function argument separators. (#9539 fixes notwithstanding). It's just that you can't indicate you want a comma-containing value, and then nothing for the false case.
@tabatkins Per your example, could we not simply omit a final value to default to no-value
Original example (with `no-value`)
/* Original example (with `no-value`) */
background-color: if(
style(--variant: success): var(--color-success-60),
style(--variant: warning): var(--color-warning-60),
style(--variant: danger): var(--color-danger-60),
style(--variant: primary): var(--color-primary),
no-value
);
/* Revised example (without `no-value`) */
background-color: if(
style(--variant: success): var(--color-success-60),
style(--variant: warning): var(--color-warning-60),
style(--variant: danger): var(--color-danger-60),
style(--variant: primary): var(--color-primary)
);
Omitting a final value would be equivalent to using no-value and may help to avoid introducing a new value:
<if()> = if(<condition>: [<declaration-value>]{1, N}; <optional-fallback-value>?)
Would this grammar paired with semicolon delimiters resolve the ambiguity here, so any of the below expressions are valid?
/* no fallback value defined, equivalent of no-value */
if(style(--x: 1): 1, 2; style(--x: 2): 3); /* 2 values: (1, 2) and (3) */
/* fallback value defined as 4 */
if(style(--x: 1): 1, 2; style(--x: 2): 3; 4); /* 3 values: (1, 2), (3), and (4) */
/* ending with a semicolon could optionally be supported, but it would be the same output as the first example, omitting the value altogether */
if(style(--x: 1): 1, 2; style(--x: 2): 3;); /* 2 values: (1, 2) and (3) */
/* not a primary syntax, but I suppose a space could also pass, which may be useful in more complex situations like when used in inside `var()` */
if(style(--x: 1): 1, 2; style(--x: 2): 3; ); /* 3 values: (1, 2), (3), and ( ) */
since this is more of an inline switch than an inline if should the default condition have special syntax like if([...] otherwise: x), if([...] default: x), if([...] *: x)? (I'm using [...] metasyntactically to denote the non-default conditions).
It would make it easier to spot the default when reading
After discussing with @fantasai, we think the best way forwards is:
-
?separator between condition and values -
,or;separator between if-true and if-false values, same as other CSS functions - Empty token stream possible to specify in the same way as one does elsewhere in CSS. If authors want to make it more clear, they can add a comment. If we want to introduce a keyword or whatever in the future, we still can. This means that
if(style(...) ? foo, bar)is parsed as "foo if true, bar if not" and if authors desirefoo, barto be parsed as a whole as the if-true value, they can doif(style(...) ? foo, bar; )(orif(style(...) ? foo, bar; /* else nothing */)with a comment).
Is
:as the separator between if-true and if-false values possible?
The question is not whether it’s possible, but whether it’s somehow better. Is there any reason other than looking like JS?