- From: Andrew Somers via GitHub <sysbot+gh@w3.org>
- Date: Sun, 05 Jun 2022 19:41:50 +0000
- To: public-css-archive@w3.org
> _I find that insufficient. I would **strongly prefer** the algorithm to be normative, and whatever tool happens to implement it is then up to the individual. Linking off to another paper evades the W3C Patent Policy and discourages independent implementation._ I would prefer it be included as well. There are internal politics that I don't fully grok, that aspect of bureaucracy is not a part of my skillset. As for the patent policy, I've discussed this with my patent attorney, and am following a plan for the basic pair-of-colors version to be safely placed in the public domain. > > _it's possible for a non-polarity-sensitive iteration, giving up accuracy by splitting the difference._ > _Its possible, but I don't see any merit in having a less accurate version._ Agreed, I am just mentioning in full disclosure as, again, I may not always be aware of organizational needs or priorities. > > _Similarly it's possible to improve accuracy by adding in a third, ..._ > _Right and here we are getting into color appearance modeling rather than colorimetry (as you know, but explaining for others following this thread). That unfortunately breaks the entire concept of CSS, because now everything depends on the entire page design._ Exactly, and party why I've only promoted the pair-version, though I do think there is a place for a third input eventually, at least for use cases such as a button that contains text and is itself on a different background. Again though, does the increased accuracy make sense for a guideline if it's more difficult to test/asses. > _Adding proximal field might be worth examining, but seems difficult and error prone. Adding room illuminance, especially in an automated way with an ambient light sensor, seems like a privacy concern._ These more advanced implementations are intended for specific embedded applications, and like I said, not likely to ever be a part of a general content guideline. > > _Regardless, I don't think having two functions is needed..._ > > ```css > --myvar = color-contrast(--color1 vs --color2, --color3); > ``` > _we don't know where `var(--myvar)` is going to be assigned._ And also @faceless2 comment: > _using this in SVG, where ideas like foreground and background can't be derived from the property._ Okay, I see the case for more than one function. Having more than one might also help keep things most clear. And opens the door to future independent functions that are specifically tuned, say, for dataviz, or for color (hue/chroma), the later of which opens up possibilities for enabling daltonization of a color palette. A long term desirable goal is that of user personalization more-so than requiring an author to create a one-size-fits-all standard. This is most evident in the use of dark mode/light mode that is rapidly gaining popularity as a user choice. But even that can go farther. I'd suggest there are 2 ideal dark modes, one for day and one for night ambience. And color insensitive users would be best served by a daltonization that is specific to their CVD type. But that is a lot for an author to cater to, so instead can be algorithmically accommodated provided there is a model in place with adequate perceptual accuracy. And this is the longer term goal of what I'm working on. That is, if an author creates a light mode and a dark mode, the other needed variations including daltonization (needed by ~5% of the population) should be achievable. The color-contrast() function is obviously an important future part of this, which is why I raised the concerns here. -- GitHub Notification of comment by Myndex Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7297#issuecomment-1146871895 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 5 June 2022 19:41:52 UTC