- From: Miriam Suzanne via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Feb 2021 20:36:48 +0000
- To: public-css-archive@w3.org
Notes from an offline conversation with Tab: - It's the `<any-value>` output, that currently makes the `switch()` function trigger IACVT fallback behavior - `cond()` avoids that by limiting output to single `<number>` values - That distinction goes out the window if a `var()` is used in the `cond()` condition or its output value, triggering IACVT anyway Which means that `cond()` provides a subset of `switch()` use-cases – and only a subset of _those cases_ would allow parse-time fallbacks (avoiding IACVT). That _sub_-subset (ordinary number _input_ & _output_) is the only use-case where the two functions differ. I'm not convinced that distinction warrants shipping two otherwise-identical-looking functions. We would need to teach authors that yes, `switch()` can handle all the use-cases, but in very particular circumstances `cond()` might provide a nicer fallback path, as long as you never put a variable inside it. I don't believe IACVT is worth that much effort to avoid. Of course @LeaVerou's initial proposal was based on a much simpler ternary `if(<condition>, <true>, <false>)`… Simplifying the math function that dramatically, it might provide a more distinct/useful shortcut. That proposal makes more sense to me than the middle-ground `cond()`. Still, it's not _much_ simpler than using switch as a ternary: ```css .example { gap: if(100% > 500px, 2em, 1em); gap: switch((100% > 500px) 2em; 1em); } ``` -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5009#issuecomment-785358600 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 February 2021 20:36:50 UTC