[css-color-5] Wide review

[svgeesus]

• A11y review (nothing in FAST seemed relevant) requested 2022-05-20
• I18n review (nothing in checklist applies) requested 2022-05-30
• Privacy review (privacy section) requested 2022-05-30
• Security review (security section) requested 2022-05-30
• TAG review

[svgeesus]

TAG review of color-mix() and color-mix() explainer

[svgeesus]

Security related to @color-profile was discussed when it was part of CSS Color 4

[svgeesus]

This contains the answers to questions posed in Self-Review Questionnaire: Security and Privacy as they relate to the current draft of CSS Color 5 which is used to set and modify the colors of various items on a Web page..

What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
None

Is this specification exposing the minimum amount of information necessary to power the feature?
Yes, we believe so.

How does this specification deal with personal information or personally-identifiable information or information derived thereof?
No personally-identifiable information.

How does this specification deal with sensitive information?
This specification does not deal with financial data, credentials, health information, location, or credentials.

Does this specification introduce new state for an origin that persists across browsing sessions?
No.

What information from the underlying platform, e.g. configuration data, is exposed by this specification to an origin?
None

Does this specification allow an origin access to sensors on a user’s device
No.

What data does this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.
None.

Does this specification enable new script execution/loading mechanisms?
No. It does allow linking to ICC profiles, but these are declarative and do not contain any scripting mechanism.

Does this specification allow an origin to access other devices?
No.

Does this specification allow an origin some measure of control over a user agent’s native UI?
No

What temporary identifiers might this this specification create or expose to the web?
None.

How does this specification distinguish between behavior in first-party and third-party contexts?
No difference.

How does this specification work in the context of a user agent’s Private Browsing or "incognito" mode?
No difference.

Does this specification have a "Security Considerations" and "Privacy Considerations" section?
Yes to both: security privacy

Does this specification allow downgrading default security characteristics?
No.

What should this questionnaire have asked?
nothing else springs to mind which would be relevant to this specification.

[svgeesus]

A Formal Objection to CSS Color 4 color-contrast() referencing the W3C Recommendation WCAG 2.1 Color Contrast has been raised by @Myndex

Resolving this would seem to require:

• removing color-contrast() from CSS Color 5
• deprecating the color-contrast portion of WCAG 2.1 and republishing the Recommendation

Moving forward to replace the functionality would require:

• helping drive APCA towards consensus
• getting a normative reference to APCA added to WCAG 3.0 (currently it is just mentioned in passing, as a possible tool to use, and the mathematics of the calculation are not referenced at all)
• creating a pair of functions (APCA does not treat text and background as identical, unlike WCAG 2.x):
  • color-contrast-text()
  • color-contrast-background()

color-contrast-text() would take a background color and a list of candidate text colors; color-contrast-background() would take a text color and a list of candidate background colors. Both functions would take an optional target L^c.

[Myndex]

Hi Chris @svgeesus

In response:

removing color-contrast() from CSS Color 5

This is really my main concern/suggestion at this time, that is, hold off until other documents catch up with useful guidance, in part due to issues with the expected time frames moving other things forward, in addition to the known deficits in the current recommendations.

deprecating the color-contrast portion of WCAG 2.1 and republishing the Recommendation

There are issues with the charter preventing this, which is why APCA was moved to Silver/WCAG 3. There has been some informal talk regarding a WCAG 2.3, but that is not much more than conjecture at this point, and not any closer to a recommendation than WCAG 3.

Something worth mentioning, due to both an apparent demand, and the expected time frame of WCAG 3, APCA is also developing independently, towards a wider-scope set of guidelines. The W3/AGWG/WCAG3 version is apca-w3, the WCAG2 backwards compatible version is bridge-pca but there are other important applications for this, and therefore the broader scope considerations and development.

helping drive APCA towards consensus

I hope to have some positive news in this regard soon, relating in part to funding for a larger set of studies.

getting a normative reference to APCA added to WCAG 3.0 (currently it is just mentioned in passing, as a possible tool to use, and the mathematics of the calculation are not referenced at all)

The current WCAG3 draft does specify "using an APCA compliant tool." I was told at the time that the editors wanted the complicated technical information as a separate white paper.

creating a pair of functions (APCA does not treat text and background as identical, unlike WCAG 2.x):
color-contrast-text()
color-contrast-background()

On this note:

• it's possible for a non-polarity-sensitive iteration, giving up accuracy by splitting the difference.
  • A non-polarity version would probably be accurate to about ~±12%
  • The current simple pair-wise version is ~±5% accuracy
    • (increasing accuracy further requires an input for total RMS page luminance)
  • In comparison, WCAG2 contrast math error is roughly +150%/-50% over the range.
• Similarly it's possible to improve accuracy by adding in a third, and possibly fourth, and fifth, color inputs (for the larger background, RMS page luminance, and ambient, respectively).
  • For simplicity, only a pair of colors are considered right now.
  • Adding in a third input is not too difficult (larger background if present),
  • though the fourth and fifth are non-trivial and not expected to ever be a part of guidelines.
  • The point here is, it's a trade-off for functional usability vs accuracy.
• Regardless, I don't think having two functions is needed—all that is needed is that the functions are aware of what property is calling them.
  • If it is being called from color: or border-color: then it needs to evaluate against the current background.
  • if it is being called from background-color: then it then it needs to evaluate against the current color:
    • In thinking over this, perhaps one other use-case is background-color: vs the larger background-color: -
      • the minimum contrast for low spatial frequency (large) items is very low,
      • this might also pre-suppose the aforementioned three-way-inputs.

[faceless2]

I don't think having two functions is needed—all that is needed is that the functions are aware of what property is calling them.

I suspect having the function evaluation depend on which property it's used for would be a very unpopular proposition, even though color-contrast() is going to be evaluated at use time. Many reasons jump out, but to give one: using this in SVG, where ideas like foreground and background can't be derived from the property.

[svgeesus]

The current WCAG3 draft does specify "using an APCA compliant tool." I was told at the time that the editors wanted the complicated technical information as a separate white paper.

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.

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.

Similarly it's possible to improve accuracy by adding in a third, and possibly fourth, and fifth, color inputs (for the larger background, RMS page luminance, and ambient, respectively).

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.

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.

Regardless, I don't think having two functions is needed—all that is needed is that the functions are aware of what property is calling them.

--myvar = color-contrast(--color1 vs --color2, --color3);

we don't know where var(--myvar) is going to be assigned.

Related:

• [css-color-5] Add currentBackgroundColor Variable #5292

[Myndex]

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...

--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.