- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Jun 2024 09:47:11 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-values?] What is the MVP for inline conditionals on custom properties?`. <details><summary>The full IRC log of that discussion</summary> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <fantasai> leaverou: Motivating use cases<br> <fantasai> leaverou: right now web components libraries introduce tons of presentational attributes<br> <fantasai> leaverou: because custom properties include parts of values<br> <fantasai> leaverou: you can transform numeric values using calc() but keywords not possible<br> <fantasai> leaverou: Canonical example is changing background-color based on a `--variant` property<br> <fantasai> leaverou: These are examples for why I started shoelace library now called WebAwesome<br> <fantasai> leaverou: [lists many examples of utility classes]<br> <fantasai> leaverou: Style queries get us a lot of the way there, but because they only work on descendants<br> <fantasai> leaverou: that doesn't let us get all the way there<br> <fantasai> leaverou: so these remain presentational attributes<br> <fantasai> leaverou: but needing to branch on a condition is very common in CSS<br> <fantasai> leaverou: several issues last few years about how can we do this<br> <fantasai> leaverou: either as a block conditional<br> <fantasai> leaverou: or inline<br> <fantasai> leaverou: there are some extremely hacky workarounds that authors use<br> <fantasai> leaverou: e.g. stting custom property to an empty token string so it gets a value or falls back. Very very hacky things<br> <fantasai> leaverou: Despite huge demand there's no progress<br> <fantasai> leaverou: I opened this issue to explore what is still useful, but still easy for implementers<br> <fantasai> leaverou: Anders said if we re-use the conditional from container queries, that let's you compare values<br> <fantasai> leaverou: and even media and supports queries<br> <fantasai> leaverou: re-use that part and then declaration values chosen based on conditional<br> <fantasai> leaverou: said it was pretty easy<br> <fantasai> leaverou: For many of these use cases, instead of having one or two values, you could have a series of subsequent conditionals<br> <fantasai> leaverou: that's nice to hvae<br> <fantasai> leaverou: but main thing is single test, can always nest<br> <fantasai> leaverou: ideally we want a block conditional that applies when matches<br> <fantasai> leaverou: but that seems to be hard, so let's do inline first<br> <fantasai> leaverou: because we need it anyway<br> <fantasai> leaverou: if it can be implemented quickly, would be an easy win<br> <TabAtkins> q+<br> <kizu> q+<br> <fantasai> TabAtkins: This sounds good.<br> <astearns> ack TabAtkins<br> <TabAtkins> https://github.com/w3c/csswg-drafts/issues/5009#issuecomment-626072319<br> <fantasai> TabAtkins: going back to previous thread, this comments lists out 3 variants of conditionals<br> <fantasai> TabAtkins: This is a variant of item 3<br> <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<br> <fantasai> TabAtkins: in simplest case that's true or false, just omit last test<br> <leaverou2> q+<br> <leaverou2> q++<br> <fantasai> TabAtkins: but I want to make sure you can sequence tests<br> <leaverou2> qq+<br> <leaverou2> q-<br> <fantasai> leaverou: it's the second grammar<br> <emilio> q- +<br> <fantasai> TabAtkins: sgtm<br> <astearns> ack fantasai<br> <astearns> ack leaverou<br> <TabAtkins> fantasai: I think that the IACVT behavior is not amazing<br> <TabAtkins> fantasai: so i dont' want us to have authors rely on it all the time bc there's no alt<br> <leaverou2> q+<br> <TabAtkins> fantasai: to the extent taht people want to switch on a custom prop, can't we do that with some sort of conditional...<br> <TabAtkins> fantasai: if you just switch basics based on conditionals you can avoid cycles easily that way<br> <fantasai> leaverou: Would be useful, but this is orthogonal<br> <TabAtkins> leaverou: a block conditional *would* be useful, but it's orthogonal<br> <TabAtkins> leaverou2: same as in JS<br> <TabAtkins> fantasai: not orthogonal from ux perspective. whether someone uses block or inline conditional is somewhat based on availability<br> <TabAtkins> fantasai: if you have both you'll use both, but if you have only one you'll shoehorn<br> <TabAtkins> fantasai: i think we should do both if we can<br> <fantasai> TabAtkins: isnt' the block version just style queries and media queries?<br> <fantasai> leaverou: Style queries only work on descendants<br> <TabAtkins> TabAtkins: getting a style query block *on the element* *requires* IACVT<br> <andruud> q+<br> <fantasai> fantasai: Shouldn't be a problem if you have standard properties set based on custom properties<br> <fantasai> TabAtkins: If you restrit it only to standard properties, that's substantially restrictive<br> <fantasai> TabAtkins: a lot of cases will want to set more variables<br> <miriam> q+<br> <fantasai> TabAtkins: Those will then need to use inline version, because that's a requirement of inline<br> <fantasai> s/because/which uses IACVT because/<br> <fantasai> TabAtkins: IACVT triggers if you write something wrong<br> <astearns> ack kizu<br> <fantasai> kizu: Wanted to show some worse things<br> <fantasai> kizu: In October 2016, I was using custom properties to switch between values using calculations<br> <fantasai> kizu: today you can use comparisons with calculations, if length is bigger or smaller use different value -- only for lengths<br> <fantasai> kizu: ?? made it possible to use values with custom properties<br> <fantasai> kizu: using type griding<br> <fantasai> kizu: a very long chain of fallbacks to registered custom property<br> <fantasai> kizu: and that let's you get any value back<br> <miriam> s/??/Jane Ori/<br> <kizu> https://github.com/w3c/csswg-drafts/issues/10064#issuecomment-2161742249<br> <fantasai> kizu: The code is very complicated<br> <fantasai> kizu: authors can now do this<br> <astearns> q?<br> <fantasai> kizu: recent article where using layers and [missed]<br> <fantasai> kizu: taking advantage of revert-layer<br> <fantasai> kizu: The need for this from authors is very high<br> <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<br> <fantasai> kizu: Also wanted to mention, how could we use registered custom properties to avoid some issues with IACVT<br> <fantasai> kizu: For those we know what types they can accept, what they can return, might make it more simple<br> <astearns> ack leaverou2<br> <astearns> ack leaverou<br> <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<br> <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<br> <fantasai> fantasai: Like we should try to make it work the right way rather than settling for IACVT<br> <astearns> ack andruud<br> <fantasai> kizu: Using animations to do this is worse<br> <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<br> <astearns> ack miriam<br> <fantasai> andruud: so we'll still run into cycle problems with block version<br> <fantasai> miriam: Do those cycles make th whole thing impossible, or do they just mean font-size is invalid and we do the condition<br> <leaverou2> ;?<br> <fantasai> andruud: for the block conditional?<br> <leaverou2> q?<br> <leaverou2> q+<br> <fantasai> andruud: I guess we could handle those cases 1 by 1<br> <fantasai> TabAtkins: dependencies will crop up over time, so hard to block ad-hoc<br> <astearns> ack leaverou<br> <fantasai> leaverou2: The block version will be inherently limited, because some values will only make sense on a single property<br> <fantasai> leaverou2: e.g. em/auto/normal<br> <fantasai> leaverou2: even if we have block version, still need inline version<br> <fantasai> leaverou2: Also you can assign conditions to a variable and then use that variable in a function, including media test<br> <fantasai> leaverou2: so handle breakpoints more easily<br> <fantasai> astearns: Lots of acknowledgement that this is important to work on<br> <fantasai> astearns: but also some concern about increasing the IACVT behavior on the web<br> <fantasai> TabAtkins: I don't believe we can solve anything in this space without IACVT<br> <fantasai> TabAtkins: so unless we can avoid cycles with some new idea, then we need to move forward with IACVT<br> <TabAtkins> fantasai: i don't object<br> <TabAtkins> fantasai: lea, can you outline the proposed syntax?<br> <leaverou2> border-radius: if(style(--button-shape: pill), infinity);<br> <ydaniv> Is this something that could later be speced to replace IACVT into a proper behavior?<br> <leaverou2> Longer example: background-color: if(<br> <leaverou2> style(--variant: success), var(--color-success-60),<br> <leaverou2> style(--variant: warning), var(--color-warning-60),<br> <leaverou2> style(--variant: danger), var(--color-danger-60),<br> <leaverou2> style(--variant: primary), var(--color-primary)<br> <leaverou2> );<br> <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<br> <TabAtkins> use a colon!<br> <florian> q+<br> <fantasai> leaverou2: seems reasonable. Could maybe use a slash<br> <bkardell_> +1 TabAtkins<br> <astearns> ack florian<br> <fantasai> leaverou2: could even use a ? and be more like JS<br> <lwarlow> q+<br> <TabAtkins> suggest we take that syntax question to the issue<br> <fantasai> florian: suggest using switch() for multiple cases, like JS<br> <fantasai> leaverou2: The conditionals here chain like else-if<br> <fantasai> leaverou2: but this expands to ranges, etc.<br> <TabAtkins> yeah, this is an if/elif/elif/else chain<br> <astearns> ack lwarlow<br> <fantasai> s/chain like else-if/chain like else-if, you have to provide the conditional each time/<br> <fantasai> lwarlow: agree with not using comma for both places<br> <fantasai> lwarlow: slash would read better<br> <leaverou2> Just noticed all examples above have no else value. This is another example: `border-radius: if(style(--button-shape: pill), infinity, .2em);`<br> <fantasai> PROPOSED: Add this to css-values-5<br> <lwarlow> +1<br> <fantasai> astearns: any objections?<br> <leaverou2> +1<br> <bkardell_> https://www.irccloud.com/pastebin/nrStwApc/<br> <fantasai> RESOVLED: Add if() to css-values-5<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10064#issuecomment-2165157958 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 June 2024 09:47:11 UTC