color contrast issues

[pkra]

While working on w3c/aria#2410 I found some contrast issues that can also be observed on https://respec.org/docs/.

• TOC
  • light & dark mode: "Tables of Content" has insufficient contrast (due to var(--tocsidebar-heading-text))
  • dark mode: .toc code {#005a9c} leads to insufficient contrast
• highlight.js: in dark mode, the color theme causes contrast issues in most code snippets, in particular html.
• WebIDL: in light mode, "WebIDL" has insufficient contrast (.idlHeader { color: var(--defrow-border,#fff)})

I'll update this issue if I find more.

[sidvishnoi]

Apart from syntax highlighting (part of ReSpec), we'd need to file above in w3c/tr-design repo, as same colors get used by Bikeshed too (base.css).

I'll try finding some time this weekend to address this. Happy to review PRs though.

[pkra]

Thanks @sidvishnoi.

Is there a way to configure the highlight.js theme in the respec configuration? It offers some themes with better contrast.

[SamB]

Hmm. The dark mode PR (#3236) said this:

This gives a "good enough" support for dark mode. Not all styles are perfected yet.
And some styles can't be overridden by the manual theme toggle (they only respect @media (prefers-color-scheme: dark) {...}).
I've tried to use W3C stylesheets's CSS variables wherever possible to avoid this, but at least styles for code syntax highlighting (including WebIDL), and definition panel aren't supported in that theme, so they won't fully respect the manual theme toggle.

Apparently relating to the following blocks of code:

respec/src/styles/highlight.css.js

Lines 27 to 43 in 19b2c0e

	/* There's no way to adapt this to "manual" theme toggle yet. */
	@media (prefers-color-scheme: dark) {
	.hljs {
	--base: #282c34;
	--mono-1: #abb2bf;
	--mono-2: #818896;
	--mono-3: #5c6370;
	--hue-1: #56b6c2;
	--hue-2: #61aeee;
	--hue-3: #c678dd;
	--hue-4: #98c379;
	--hue-5: #e06c75;
	--hue-5-2: #be5046;
	--hue-6: #d19a66;
	--hue-6-2: #e6c07b;
	}
	}

respec/src/styles/algorithms.css.js

Lines 24 to 31 in 19b2c0e

	/* There's no way to adapt this to "manual" theme toggle yet. */
	@media (prefers-color-scheme: dark) {
	:root {
	--assertion-border: #444;
	--assertion-bg: var(--borderedblock-bg);
	--assertion-text: var(--text);
	}
	}

It seems that the issue is that https://github.com/w3c/tr-design/blob/gh-pages/src/fixup.js can disable W3C's dark-mode stylesheet but nobody else's.

#4687 is basically about how to handle it here, w3c/tr-design#349 was about having fixup.js set a global class, but that (afaik) won't ultimately work for viewing a pre-processed spec with JavaScript turned off. I filed w3c/tr-design#363 requesting an explanation of how to use the feature.

[pkra]

w3c/tr-design#364 will fix some of this.

[TimvdLippe]

Here's another one that I found while working on dark mode for Respec documents: w3c/tr-design#366

[niklasl]

I've gotten the respec dark mode to work with both browser/OS control and manual theme toggle override in w3c/rdf-primer#24. That's done along the lines here. It basically duplicates the dark styles on body.darkmode .hljs, which I think could be done in a more robust way upstream.

(Note also that body { color-scheme: light; } body.darkmode { color-scheme: dark; } makes the dark mode manual theme toggle work in SVG:s.)

Would a dedicated PR for doing it this way to fix highlight.js-usage in ReSpec be welcome?

[Tpt]

I think the tricky bit is that ReSpec should work without JavaScript so the selector for dark more can't just rely on body.darkmode that is introduced using JavaScript from tr-design.

We need something like "body.darkmode OR (NO_JAVASCRIPT AND @media (prefers-color-scheme: dark)".

A way might be to make tr-design introduce a lightmode class. This way if JS in enabled then either lightmode or darkmode is present.

[niklasl]

@Tpt You're right; this should definitely work without JS. And I see now how the darkmode class is added to the body element by JS if in dark mode. (I was fooled into thinking it worked through media-selector alone by default. But of course it doesn't; that's what I've overridden!)

I think your proposed solution (JS-injected lightmode or darkmode) is promising!

(It seemed that Bikshed-based specs seemed too work (e.g. the File API spec), but on a quick inspection, I see the same darkmode class injected (by JS) on the body when I'm in dark mode and user preference is "auto".)

[niklasl]

So, one option is to override the default and media-query-controlled highlights by.lightmode .hljs and .darkmode .hljs rules (using more variables to reduce color code repetitions).

An alternative is to use light-dark(COLOR1, COLOR2) in the variables defined by .hljs and then overriding OS/browser scheme selection with just body.lightmode { color-scheme: light; } body.darkmode { color-scheme: dark; }. (It seems light-dark() is available for 86.9% of global users at this time according to caniuse; ~ 8% less than prefers-color-scheme media query version at 95.16%.)

(Aside: It is also possible to have a purely CSS-based manual override, e.g. through a <select id="colorscheme">... and body:has(#colorscheme [value="light"]:checked) { color-scheme: light } body:has(#colorscheme [value="dark"]:checked) { color-scheme: dark }. But that'd require an overhaul of the UI controls.)