- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Sep 2024 18:54:01 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-color] [css-ui-4] Authors should have access to accent-color value to use in their code`.
<details><summary>The full IRC log of that discussion</summary>
<kbabbitt> lea: there's an accent-color property which lets you set the accent color for whole page or subtree<br>
<kbabbitt> ...native ontrols take advantage of it to adapt their display<br>
<kbabbitt> ...even though we have a system color called accentcolor, it returns the os default system color<br>
<kbabbitt> ...seems like an easy win to have it return value of accent-color property<br>
<kbabbitt> ...we have precent for system colors resolving differently based on other properties<br>
<kbabbitt> ... <examples><br>
<kbabbitt> ... would give web components and components in general ability to adapt in that way same as native components<br>
<astearns> ack lea<br>
<kbabbitt> ... cannot be an environment variable because it's different for subtree<br>
<kbabbitt> fantasai: if we look at the work on base stylesheet for form controls, where tims proposed to use currentcolor and transparent backround<br>
<kbabbitt> ...you often need another color to <missed.<br>
<chrishtr> q+<br>
<kbabbitt> ... author would be able to use accent-color for that<br>
<astearns> ack fantasai<br>
<astearns> ack chrishtr<br>
<kbabbitt> chrishtr: is accent-color inherited?<br>
<kbabbitt> lea: yes<br>
<fantasai> s/<missed/e.g. identify the selected item/<br>
<kbabbitt> chrishtr: so then the color would start out as the same as the text color system color?<br>
<kbabbitt> lea: OS default accent color<br>
<emilio> q+<br>
<kbabbitt> chrishtr: default would be OS default accent color provied by UA, if overrided subtree would receive new value<br>
<kbabbitt> ... would this apply to shadow DOM?<br>
<kbabbitt> lea: I believe inherited properties do<br>
<fantasai> https://www.w3.org/TR/css-ui-4/#widget-accent<br>
<kbabbitt> chrishtr: devlopers can already figure it out?<br>
<astearns> ack emilio<br>
<kbabbitt> emilio: <missed><br>
<kbabbitt> emilio: you want to make system colors based on the accent color?<br>
<kbabbitt> lea: yes<br>
<kbabbitt> emilio: you would also need text accent color<br>
<kbabbitt> ... we need to deal with cycles<br>
<kbabbitt> ... <missed><br>
<kbabbitt> ... you set accent-color to the system accent color, now you need to say what happens when this property resolves against the parent<br>
<lea> Proposed resolution: accentcolor and accentcolortext resolve relative to the accent-color property. accent-color: accentColor resolves relative to the parent.<br>
<kbabbitt> ... it's a bit weird with childrens' color schemes<br>
<kbabbitt> ...anyway we need to sort that out, a bit weird you lose system accent color once you override it<br>
<lea> q?<br>
<ntim> What is accentcolortext ?<br>
<kbabbitt> lea: you dont neessarily lose system color, we could define it relative to the parent or resolve realtave to acccent color on the root then you get the os color<br>
<masonf> +1 to this question: what is accentcolortext?<br>
<hober> q+<br>
<ntim> oh I guess it's the text used against an accentcolor background<br>
<masonf> ahh ok. The contrasting color. Thanks.<br>
<kbabbitt> emilio: the accent color system color could be different in @@@ so registered custom property doesn't work as a workaround<br>
<oriol> Wondering about `accent-color: currentcolor; color: accentcolor`<br>
<kbabbitt> fantasai: whit if instead of resolving accent-color: accentcolor against parent, resolve against ???<br>
<kbabbitt> emilio: maybe it's not a big deal because you could set it back to auto<br>
<kbabbitt> fantasai: I don't see a use case for setting accent-color: accentcolor and wanting to change it<br>
<ntim> +1 to oriol's question<br>
<kbabbitt> emilio: once you set accentcolor to something, you can't get it back<br>
<kbabbitt> hober: my initial thought was accentcolortext was a bad name because on sopme [platforms accentcolor s a background som eits a foreground<br>
<kbabbitt> but we could have contrast color accent color<br>
<kbabbitt> s/but/...but<br>
<kbabbitt> fantasai: it would be weird if accent-color property changed with accentcolor<br>
<kbabbitt> lea: accentcolor is defined in css color<br>
<fantasai> ss/<br>
<hober> s/contrast color accent color/contrast-color(accentColor)/<br>
<astearns> s/accentcolor is defined/accentcolortext is defined<br>
<fantasai> https://www.w3.org/TR/css-color-4/#valdef-color-accentcolor<br>
<lea> https://drafts.csswg.org/css-color-4/#valdef-color-accentcolortext<br>
<kbabbitt> emilio: oriol also mentioned this also causes issuse where you have accent-color: currentcolor or accentcolor, you need to define @@@<br>
<hober> q?<br>
<hober> ack<br>
<kbabbitt> fantasai: agree with emilio that this is an editorial that needs to be solved but it's not complicated<br>
<fantasai> s/editorial/issue/<br>
<kbabbitt> astearns: is that where we are?<br>
<emilio> q+<br>
<kbabbitt> fantasai: funtamendal question is: accentcolor system color defined in color-4 references system accent color, will we have a property that allows setting accent-color, instead of being fixed, in same way currentcolor references color property, accentcolor referenes accent-color property<br>
<emilio> ack hober<br>
<florian> q+<br>
<astearns> ack emilio<br>
<fantasai> s/will we/we already/<br>
<kbabbitt> emilio: something you mentioned, system colors right now compute to an actual color<br>
<fantasai> s/instead of being fixed/proposal is instead of being fixed/<br>
<kbabbitt> ...do we want to make accentcolor and accentcolortext keywords that inherit through or just resolve at computed value time?<br>
<kbabbitt> fantasai: I htink you want to give them same treatment as crurrentcolor<br>
<kbabbitt> florian: for privacy reasons I think it's not reasonable to expose it as an actual color<br>
<kbabbitt> emilio: what's the privacy issue?<br>
<astearns> ack florian<br>
<kbabbitt> florian: two parts, one is acceing thjrough tree to value that the author has set<br>
<kbabbitt> ...but if you haven't set anything, accentcolor depends on os settings<br>
<lea> q?<br>
<kbabbitt> ...so there's dobule use case. one is a convenience to the author<br>
<kbabbitt> emilio: it doesn't matter because the keywords resolve in getcomputedstyle anyway<br>
<lea> q+ the part that depends on OS settings doesn't change though<br>
<kbabbitt> florian: two use cases, one is learning or using the os accent color<br>
<kbabbitt> ...one is convenience of figuring out what the accent color you set yourself is<br>
<kbabbitt> ...if we were only talking abou tlatter, it's kind of nice to have it, it could resolve to an actual color, wouldn't be terrible if we didn't<br>
<kbabbitt> ...less convenient to do that but doable\<br>
<kbabbitt> ...if we also want to expose accent color from outside browser, that's a fingerprintingh concern<br>
<kbabbitt> emilio: that concern already exists from not exposing @@@<br>
<kbabbitt> ...OS accent color keyword is shipped in gecko and webkit<br>
<ethanjv> s/abou tlatter/about latter/<br>
<kbabbitt> ...if you wnat to prevent fingerprinting of system colors you cannot expose OS setting<br>
<kbabbitt> ntim: Safari hardcodes accentcolor to blue<br>
<astearns> q+ lea<br>
<kbabbitt> emilio: I don't think we want to inent something complicated<br>
<ethanjv> s/fingerprintingh/fingerprinting/<br>
<kbabbitt> florian: one of the motivating use cases was not at the javascript evel but OS level to know what the OS color is<br>
<emeyer> q?<br>
<ethanjv> s/inent/intent/<br>
<kbabbitt> ...in Safari if you query the color, ti will say blue but will still render as OS color<br>
<kbabbitt> ...bt I think that's the use case that's asked in the ???<br>
<kbabbitt> ...OS uses this color and I want to use it too<br>
<kbabbitt> ...either "no" or yes but I can't discover what it is<br>
<astearns> ack lea<br>
<kbabbitt> lea: we seem to be discussing an issue that's not related to @@@<br>
<kbabbitt> ...whatever browser are already doing, they can cointineu to due<br>
<kbabbitt> ...only change is what happens if accent-color is also provided by author<br>
<kbabbitt> ...what happens when accent-color is not set is orthogonal<br>
<kbabbitt> emilio: if yiu want to make accentcolor a keyword<br>
<ethanjv> s/cointineu to due/continue to do/<br>
<kbabbitt> lea: it already exists<br>
<kbabbitt> emilio: it doesn't resolve aty computed value time<br>
<kbabbitt> lea: doesn't matter when it resolves<br>
<kbabbitt> lea: I wouldn't take ? as a model<br>
<emilio> s/?/currentColor<br>
<matthieud> s/?/CanvasText<br>
<fantasai> s/as a model/as a model so much as CanvasText/<br>
<kbabbitt> emilio: so we are not changing when it is resolved, that's fine with me<br>
<dbaron> (ignore matthieud's substitution when preparing minutes)<br>
<lea> canvas/canvastext and color-scheme seems identical to me: it can be set by the author, but there is also an OS default value that can change<br>
<kbabbitt> ...fantasai seemed to want the currentcolor behavior, that seems not great because if you have matching background and text colors, if you change accentcolor in the tree wihtout settting anything, ?<br>
<kbabbitt> fantasai: we have border color and on one dcouemtn I set to currentcolor, other I set to accentcolor<br>
<kbabbitt> ... or text-emphasis<br>
<astearns> q?<br>
<kbabbitt> emilio: <missed><br>
<kbabbitt> ...that would change the accent color text but not the background which is odd<br>
<kbabbitt> lea: does this concern apply to canvas and canvastext as well?<br>
<kbabbitt> emilio: that's my point, the reason system colors resolve at computed value time is to prevent this kind of thing where switching color scheme without settingh background would make text unreadable<br>
<kbabbitt> lea: not a new problem<br>
<kbabbitt> emilio: not a problem aty all if we ckeep accentcolor resolving at computed value time<br>
<kbabbitt> lea: why do we need to change it to work like currentcolor?<br>
<emilio> <style>:root { background-color: AccentColor; color: AccentColorText }</style><p style="accent-color: blue">Foo<br>
<kbabbitt> emilio: I don't think we need to but fantasai wanted to<br>
<kbabbitt> fantasai: I don't know if it's required, but ???<br>
<kbabbitt> lea: I agree it's important to make it work with color-mix, but I don't think ???? is needed<br>
<fantasai> s/<missed>/:root { background: AccentColor; color: AccentColorText; accent-color: something } section { accent-color: somethingelse } would change the text color but not the background color<br>
<kbabbitt> emilio: then you actually want it to resolve at computed value time, that's easier<br>
<kbabbitt> ...it works in both cases, I think<br>
<florian> q+<br>
<lea> Proposed resolution: accentcolor and accentcolortext resolve relative to the accent-color property. accent-color: accentColor resolves relative to the parent.<br>
<emilio> Proposed resolution: accentcolor and accentcolortext resolve relative to the accent-color property at computed-value time. accent-color: accentColor resolves relative to the parent.<br>
<ntim> what about `accent-color: currentColor; color: accentColor;` ?<br>
<kbabbitt> florian: unless I'm missing something this won't be usabel<br>
<fantasai> Probably need accentColor to resolve against the parent in both color and accent-color<br>
<kbabbitt> ...it will be usable if the author has actually set an accent-color<br>
<lea> fantasai: why?<br>
<kbabbitt> ...but if they haven't we're giong to default to system accent color which UA is lying about for fingreprinting reasons<br>
<ntim> lea: how do you define the resolution of `accent-color: currentColor; color: accentColor;` ?<br>
<chrishtr> q+<br>
<fantasai> ... yeah that wouldn't work nm<br>
<kbabbitt> ...if you set to orange, it will be orange, if you don't set it will be blue even if it's pink<br>
<astearns> ack florian<br>
<kbabbitt> emilio: unrelated to this resolution<br>
<fantasai> but the see oriol/ntim's question about cycles<br>
<kbabbitt> florian: currently accentcolor does not reflect the property and is used less because browser can and do lie about it<br>
<kbabbitt> ...if we do this, it will be ???<br>
<ntim> q+<br>
<kbabbitt> emklio: browsers lie about system colors all the time<br>
<lea> q+<br>
<kbabbitt> florian: in my view, browsers lie about stste colors all the time and its fine because authors know that, just not use them<br>
<kbabbitt> ...nbut if we make this a combination of a lie and something useful, some of the time it will be useful, sometimes it will be wrong, and it's not good to tempt authors into that<br>
<astearns> ack florian<br>
<astearns> ack chrishtr<br>
<kbabbitt> chrishtr: I think the browser would lie when a developer tries to read back the color but not when painting the screen<br>
<kbabbitt> ...if you use it in CSS it will have the correct system color<br>
<kbabbitt> florian: if we don't resolve at computed value time I would agree, but if we resolve at coputed value time it has become a specific color<br>
<lea> Current behavior: https://result.dabblet.com/gist/d9354b57012bc1f9eaf8edfbc2b39bed/76e4ff46647e8e44936801620ace82ae882d82ee<br>
<kbabbitt> astearns: if it is using the system color at computed value time, it could remain the accentcolor system color<br>
<emilio> q+<br>
<kbabbitt> florain: but we don't have an ?? that tells us what it is we have a lie that tells us it's blue<br>
<ntim> +1 to florian's argument<br>
<kbabbitt> ...if we had kept it as a keyword I think it would work<br>
<kbabbitt> ...but if we resolve to a specific color the lie becomes the truth<br>
<kbabbitt> emilio: if we keep it as a keyword we also need to implement exceptions for canvas, etc<br>
<ntim> If people use AccentColor on their sites, they'll get the hardcoded color unless someone sets accent-color, which is not really useful<br>
<kbabbitt> ...I don't think we want to go that route<br>
<astearns> zakim, close queue<br>
<Zakim> ok, astearns, the speaker queue is closed<br>
<kbabbitt> ...the browser can choose to make system colors ? or not depending on...<br>
<astearns> q?<br>
<kbabbitt> ...in windows high contrast mode, browser will expose actual system colors, those will be useful<br>
<kbabbitt> ...my point is, I don't think we should ? a mitigation strategy here because we already have one<br>
<kbabbitt> ...we can discuss in some other issue, it affects all system colors<br>
<astearns> ack ntim<br>
<emilio> s/?/invent/<br>
<kbabbitt> ntim: florian's point is, if people start using accent color on their site, they could get fingerprinted, unless someone sets accent-color property<br>
<kbabbitt> emilio: browser cannot tell whether syste accent color is red or blue<br>
<kbabbitt> ntim: say you have a ? form control, system color setting is set to red<br>
<kbabbitt> ...another element on page usees accentcolor keyword that element will have hardcoded blue color while native control will have red color<br>
<kbabbitt> emilio: that may be a bug in webkit<br>
<kbabbitt> florian: it's deliberate that it's blue because it protects fingerprinting and authors know that<br>
<kbabbitt> ntim: how does this relate to tab's proposal for custom color schemes?<br>
<kbabbitt> tabatkins: I don't think it has any affect on there; it's slightly realted in that custom color scheems need to be careful about not ? the system color scheme<br>
<kbabbitt> ...other main issues, fingerprinting etc don't seem to apply to custom color scheme<br>
<astearns> ack lea<br>
<kbabbitt> lea: I 've been looking into what happens right now, posted a demo for current behavior<br>
<kbabbitt> ...set system color to pink or something<br>
<kbabbitt> ...regardless of what browsers do, cSS is internally consistent<br>
<kbabbitt> ...you get a live version of what's displayed in accent color<br>
<kbabbitt> ...Firefox and CHrome give you pink, Webkit is lying and gives you blue<br>
<kbabbitt> ...either way it's consistent, mix with white gives you a lighter pink or blue<br>
<kbabbitt> emilio: that was exactly my point<br>
<florian> q+<br>
<astearns> ack emilio<br>
<emilio> ack emilio<br>
<kbabbitt> florian: the reason it wouldn't be useful, yes you get blue and if you mix it you get lighter blue, but actual native controls are pink iN Safari<br>
<emilio> q+<br>
<kbabbitt> ...this is a hint that since some browsers do this on purpose, in genreal using system accentcolor keyword is a bad idea since it will backfire on authors<br>
<kbabbitt> astearns: I'm not hearing consensus, we're not resolving today, we need to take it back to the issue<br>
<astearns> zakim, open queue<br>
<Zakim> ok, astearns, the speaker queue is open<br>
<emilio> FWIW, Firefox lies about the accent color on Windows, but makes the form controls blue too, not the OS accent color<br>
<emilio> Seems WebKit should do that<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5900#issuecomment-2377703623 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 26 September 2024 18:54:03 UTC