Re: [csswg-drafts] [css-values-5] What is the MVP for inline conditionals on custom properties? (#10064)

`if(foo(): bar, valid-empty)` is longer than `if(foo(): bar, else:)`, so if the concern was terseness that's worse. It also requires us to reserve a new global keyword, which isn't needed in any other arbitrary-substitution function that wants to resolve to empty for some case.

It also doesn't solve the bigger problem of "can't tell whether the last clause is a catch-all or not".

>  I'd +1 to @LeaVerou for disallowing : from it.

Banning `:` doesn't fix anything, you need to ban `?` instead. And I'm relatively firmly against imposing arbitrary restrictions on the decl-value, which aren't present in *any other arbitrary-substitution function*, just to avoid having to type `else:` when you have a catch-all (like almost every other conditional in the world does).

> My optional-else proposal tries <cond> ':' <declaration-value> first, and if that matches, 

We'd have to put some *really* wide restrictions on what the un-prefixed `decl-value` can contain, to avoid things like authors using a new condition type being treated like a catch-all in older browsers.

> So basically any catch-all value with a : requires an else:.

Yeah, I think that's the wideness we would need.

But I'd prefer to push back on these special restrictions just for the purpose of avoiding `else`. I think your proposal *works* if we're forced into it, but I'd like to see if the WG actually feels like this needs addressing first before accepting the compromise.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10064#issuecomment-2327234082 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 3 September 2024 19:11:01 UTC