- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Aug 2023 16:47:56 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-color] Add a function to allow authors to specify colors reacting to `color-scheme` ``, and agreed to the following:
* `RESOLVED: Add light-dark() fuction that returns a color based on the color scheme.`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> emilio: discussed briefly in F2F<br>
<fantasai> emilio: Tab's proposal about having a variable-like thing ...<br>
<fantasai> emilio: I'm not sure this is ready for resolution. I added Agenda+ F2F and we didn't remove.<br>
<fantasai> TabAtkins: I'm happy to discuss my proposal. Two things to consider<br>
<fantasai> TabAtkins: The first and easiest one is, just having a color function that responds to color scheme<br>
<fantasai> TabAtkins: this doesn't require anything fancy<br>
<fantasai> TabAtkins: Proposed syntax is ...<br>
<TabAtkins> color-scheme( <color>#{2} | [ <custom-ident> <color> ]#{2,} )<br>
<fantasai> TabAtkins: You can either provide two colors<br>
<fantasai> TabAtkins: or provide color scheme ident and color pairs<br>
<fantasai> TabAtkins: This matches behavior of existing function that browsers have access to<br>
<fantasai> TabAtkins: I know that Chrome and Firefox have something like a light-dark() function<br>
<fantasai> TabAtkins: it's simply a color, goes where colors go, responds to color scheme<br>
<fantasai> TabAtkins: other one is if you want to do other stuff, e.g. turn shadows on<br>
<fantasai> TabAtkins: and that requires var-like semantics<br>
<fantasai> TabAtkins: but simple color one will solve a majority of cases we care about here and be very simple<br>
<fantasai> fantasai: If you only spec 2 colors, and we later introduce a new color scheme, what happens?<br>
<emilio> fantasai: If you only specify two colors and then we add a third color-scheme, then what?<br>
<fantasai> TabAtkins: suggest to default to "light"<br>
<fantasai> TabAtkins: same issue applies with the list option<br>
<fantasai> TabAtkins: in that case, maybe choose first one. or maybe choose "light" if specified<br>
<Rossen_> q?<br>
<Rossen_> ack fantasai<br>
<emilio> fantasai: one of the nice things about ??? is that it makes very explicit what goes where<br>
<emilio> ... like minmax() in grid<br>
<emilio> ... so I understand that at some point for more schemes we want to tag individual values<br>
<TabAtkins> s/???/chrome's internal function/<br>
<emilio> ... but currently we just have light and dark<br>
<emilio> ... I think it's a lot better to have light-dark like chrome has<br>
<bramus> q+<br>
<TabAtkins> q+<br>
<emilio> ... at some point in the future that could become effectively syntactic sugar for a more-comprehensive function<br>
<emilio> ... but even if we have that we could have a light-dark() since that's the more common thing<br>
<Rossen_> ack bramus<br>
<fantasai> bramus: I want to support what fantasai said, start with light-dark() and have it be syntactic sugar for color-scheme() or whatever in the future<br>
<TabAtkins> I'm fine with `light-dark()` even if we have more schemes in the future, it's still a reasonable name.<br>
<fantasai> bramus: Internally Chromium had light-dark-color(), but then changed to light-dark() which allowed using in properties other than colors<br>
<Rossen_> ack TabAtkins<br>
<fantasai> TabAtkins: I'm fine with light-dark() as a name. That's still fine if/when we do define more color schemes<br>
<fantasai> TabAtkins: For having a second function that has var-like semantics, but can do anything ...<br>
<Rossen_> q?<br>
<fantasai> TabAtkins: makes sense to me, but that should be a separate thing so that we have a well-defined <color> that can be accepted in places that accetp colors<br>
<fantasai> +!<br>
<fantasai> +1<br>
<fantasai> emilio: Shoudl we resolve on light-dark-color() and potentially extend to more color schemes or value types in the future?<br>
<emilio> I'd go just for light-dark() as a name fwiw<br>
<emilio> but light-dark-color() wfm<br>
<fantasai> Rossen_: Proposed resolution is to add a light-dark() or light-dark-color() color ... extend for other color schemes later<br>
<TabAtkins> light-dark-value() for the "anything" one?<br>
<fantasai> dholbert: if we do want to add an additional function name, light-dark() sounds like a more generic thing<br>
<fantasai> dholbert: so might want to use light-dark-color() for the color-specific thing<br>
<fantasai> dholbert: but that's just naming thing<br>
<Rossen_> ack fantasai<br>
<emilio> fantasai: thought about what dholbert just said, but the color is going to be by far the most commonly used thing<br>
<emilio> ... so might make sense to have light-dark() for color and something longer for the value syntax<br>
<emilio> dholbert: makes sense<br>
<emilio> fantasai: poll on the name?<br>
<fantasai> Rossen_: Let's pick one and discuss in the issue.<br>
<TabAtkins> (and note proposals to, say, name nth-value() to grab an arbitrary value from the list. "value" as an indicator of arbitrary, var-like behavior is somewhat leaned toward as a pattern.)<br>
<TabAtkins> 1) light-dark-color()<br>
<fantasai> POLL: 1) light-dark-color 2) light-dark<br>
<TabAtkins> 2) light-dark()<br>
<fantasai> 2<br>
<emilio> 2<br>
<TabAtkins> 2<br>
<bramus> 1<br>
<miriam> either<br>
<dholbert> 2, per fantasai's note on making-the-common-thing-easy<br>
<rachelandrew> 2<br>
<oriol> abstain<br>
<masonf> 2<br>
<bramus> q+<br>
<fantasai> bramus: What about schemed-color() etc.? Would we then have schemed-color() map to light-dark() and schemed-value() to light-dark-value() ?<br>
<fantasai> TabAtkins: more color schemes in the future, but light-dark is just for these schemes<br>
<Rossen_> ack bramus<br>
<fantasai> bramus: returns a color?<br>
<fantasai> TabAtkins: yes. If we want value, we can use light-dark-value()<br>
<fantasai> RESOLVED: Add light-dark() fuction that returns a color based on the color scheme.<br>
<fantasai> s/fuction/function/<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7561#issuecomment-1671786293 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 9 August 2023 16:47:58 UTC