Csswg-drafts: [css-color-adjust-1] Define what happens to SVG in forced colors mode

[fantasai]

It's not clear what should happen to SVG elements in forced colors mode. Do text content elements get backplates? Is anything else affected? What do we need to put in the spec to correctly handle SVG?

[fantasai]

Specced that <svg> elements get forced-color-adjust: none while <text> and <foreignObject> turn it back to auto for now. @AmeliaBR and @atanassov might have further comments on what should happen here...

[AmeliaBR]

Setting forced-color-adjust: none on SVG elements by default would _break_ any SVG that uses currentColor for accessibility purposes (to intentionally sync with any forced color changes). So that's a definite no-go.

That said, I wouldn't recommend that user agents directly adjust any colors on SVG other than for text, and they should only adjust text colors if they are adding in the glyph backplate effect to preserve contrast.

(Authors could of course use the media query & system colors to create a color scheme for data viz or icons that respects the user's palette while still going beyond what currentColor can do. See Eric Bailey's CSS-Tricks article for examples.)

[AmeliaBR]

FYI, EdgeHTML currently doesn't do anything with SVG text when WHCM is on: no backplate, and no change to the fill color (unless the author is using fill: currentColor).

[AmeliaBR]

To sum up my previous comment as a concrete recommendation:

• Remove the current spec text defining UA stylesheet rules about forced-color-adjust and SVG elements.

• Add an item to the list of Properties Affected by Forced Colors Mode, fill: currentColor !important; fill-opacity: 1 !important, but add a qualification that this should only apply for HTML elements and for SVG text elements (or descendants of text), and should only apply on SVG if the user agent is able to generate an opposing-color text backplate.

  The exact color of the backplate would as usual depend on the context — e.g., inside a <button>, where currentColor would be ButtonText, the backplate color would be ButtonFace.

[fantasai]

Setting forced-color-adjust: none on SVG elements by default would break any SVG that uses currentColor for accessibility purposes (to intentionally sync with any forced color changes). So that's a definite no-go.

Why would that break anything? It doesn't have any effect on <color> values.

[AmeliaBR]

Why would that break anything? It doesn't have any effect on <color> values.

It resets color and therefore currentColor & the ability of currentColor to sync according to the forced-color mode.

Currently, if I create an SVG icon and set it color: purple and fill: currentColor, the fill will change in high contrast mode to the WHCM text color or button color, depending on context. If you set forced-color-adjust: none on the same element, it would stay purple.

[kbabbitt]

• Add an item to the list of Properties Affected by Forced Colors Mode, fill: currentColor !important; fill-opacity: 1 !important, but add a qualification that this should only apply for HTML elements and for SVG text elements (or descendants of text), and should only apply on SVG if the user agent is able to generate an opposing-color text backplate.

+1 for fill-opacity: 1 !important (and stroke-opacity: 1 !important) being added for forced colors mode.

[alisonmaher]

I was hoping to re-address this issue, specifically regarding what should happen to SVG <text> in forced colors mode. After discussing this with @atanassov, there appear to be a couple concerns with setting forced-color-adjust: auto; for such elements:

1. Adjusting the styles for SVG textual elements creates an inconsistent experience when the rest of the SVG element is not being styled for forced colors mode.
2. More importantly, the backplate becomes difficult to define in this case. For example, what should the backplate look like for text on a path?

Considering this, I would suggest that we do not apply forced colors to SVG <text>, and only apply forced-color-adjust: auto; to <foreignObject> SVG elements.

[css-meeting-bot]

The CSS Working Group just discussed [css-color-adjust-1] Define what happens to SVG in forced colors mode, and agreed to the following:

• RESOLVED: Accept proposed definition

The full IRC log of that discussion

<dael> Topic: [css-color-adjust-1] Define what happens to SVG in forced colors mode

<dael> github: https://github.com/w3c/csswg-drafts/issues/3855

<dael> Rossen_: I can introduce this

<dael> Rossen_: This issue defined how forced colors supposed to effect SVG. Previous resolution was that forced colors should apply to text element and foreign object element. foriegn object makes sense b/c switching to HTML and all forced color rules apply

<dael> Rossen_: Additonal complication and prop change is what seemed reasonable to expect text element effected by force colors but in effect when text gets forced color applied in addition a background plate should be rendered so overall contrast ratio is as defined through system. THis proved to be ineffective and counter intutive for svg

<dael> Rossen_: A few cases where this might make sense but in general since no svg elements except these are effected by forced colors overall effect becomes incongruent. prop revert including font

<dael> Rossen_: Computing backplate on a path is hard to define and deterimental. You either get bounding box is is more then necessary or you do per glyph which is bad

<dael> Rossen_: Prop: exclude text elemented of svg from being effected by force colors

<dael> chris: Agree, makes most sense

<dael> AmeliaBR: sgtm

<dael> AmeliaBR: Example in spec may be useful about using MQ to make SVG work with high contrast. Default it's best not tot ry and do too much

<dael> AmeliaBR: Do we need to call out foreign object or do colors naturally apply to content inside? Do we need ot add colors to the foreign object itself or enough content inside has the rules if it's html

<dael> fantasai: We should set force color adjust none on SVG root and switch to auto on foreign object

<dael> chris: agree [missed]

<AmeliaBR> +1 to fantasai's solution

<dael> chris: You don't want color value set outside inheriting in. Need to be explicitly set on foreign object

<fantasai> which is what's posted in the issue at https://github.com/w3c/csswg-drafts/issues/3855#issuecomment-485023552 :)

<dael> Rossen_: That's the impl we landed on. +1 to fantasai

<dael> Rossen_: Other suggestions or objections for that resolution?

<dael> RESOLVED: Accept proposed definition