Add `color_scheme_dark` member and themeable members (colors only) by christianliebel · Pull Request #1207 · w3c/manifest

christianliebel · 2026-02-10T09:55:32Z

Closes #975

This change (choose at least one, delete ones that don't apply):

Adds new normative requirements

Implementation commitment (delete if not making normative changes):

If change is normative, and it adds or changes a member:

updated JSON schema

Commit message:

Add color_scheme_dark member and themeable members

Person merging, please make sure that commits are squashed with one of the following as a commit message prefix:

chore:
editorial:
BREAKING CHANGE:
And use none if it's a normative change

Preview | Diff

Copilot

Pull request overview

Adds a manifest-level mechanism to specify dark-mode overrides for color-related members, addressing the need to provide different theme/background colors for light vs. dark color schemes (Issue #975).

Changes:

Marks theme_color and background_color as “themeable members”.
Introduces a new color_scheme_dark manifest member (ordered map) to hold dark-theme overrides.
Adds a processing algorithm for color_scheme_dark and hooks it into the manifest processing steps.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

index.html

Copilot · 2026-02-10T10:01:36Z

index.html

+          The [=manifest's=] <code><dfn data-export="" data-dfn-for=
+          "manifest">color_scheme_dark</dfn></code> member is an [=ordered
+          map=] whose keys are the names of [=themeable members=], while the
+          values are their corresponding theme overrides.


"theme overrides" is introduced here but not defined elsewhere in the document. Consider either defining what a "theme override" is (including its value type) or rephrasing to state that the values are the same types as the corresponding members (e.g., color strings) and are processed with the existing color-member processing algorithm.

Suggested change

values are their corresponding theme overrides.

values are their corresponding <dfn>theme overrides</dfn>. A theme

override is a value of the same type as its corresponding

[=themeable member=] (for example, a color string for a color

member) and is processed using that member's existing processing

algorithm.

If we do this, we could avoid having the algorithm below. But - I'm generally a fan of algorithms in spec.....

One idea without the algorithm, we can:

When we define a 'themeable member', we can say the member may be changed based the color theme of the operating system.

We define "color_scheme_dark" as a "theme"

When parsing a 'theme', kind of like *_Localized, we apply these values on top of the manifest json if that theme is being used. This makes it so we don't have to define parsing of the fields.

What do you think?

Copilot · 2026-02-10T10:01:37Z

index.html

+        </p>
+        <aside class="example" title="Example manifest with a dark theme">
+          <pre class="json">
+            { 


The JSON example contains trailing whitespace after the opening { on the first line of the snippet. Please remove the trailing space to keep the spec source clean (and avoid whitespace-only diffs if tooling normalizes it).

Suggested change

{

{

dmurph

I think the current version should 'work' - but interested in your thoughts on alternative design here.
Sorry for review delay - was trying to think about the alternative way here.

If you prefer this way, then we can keep it. Happy to hear others thoughts though

dmurph · 2026-02-13T18:27:48Z

index.html

+          The [=manifest's=] <code><dfn data-export="" data-dfn-for=
+          "manifest">color_scheme_dark</dfn></code> member is an [=ordered
+          map=] whose keys are the names of [=themeable members=], while the
+          values are their corresponding theme overrides.


If we do this, we could avoid having the algorithm below. But - I'm generally a fan of algorithms in spec.....

One idea without the algorithm, we can:

When we define a 'themeable member', we can say the member may be changed based the color theme of the operating system.

We define "color_scheme_dark" as a "theme"

When parsing a 'theme', kind of like *_Localized, we apply these values on top of the manifest json if that theme is being used. This makes it so we don't have to define parsing of the fields.

What do you think?

marcoscaceres · 2026-02-16T04:05:40Z

index.html

          <dfn>theme color</dfn> is defined in [[HTML]].
        </p>
+        <p>
+          The [=manifest/theme_color=] member is a [=themeable member=].


This should be:

Suggested change

The [=manifest/theme_color=] member is a [=themeable member=].

The [=manifest/theme_color=] member is a [=manifest/themeable member=].

marcoscaceres · 2026-02-16T04:06:03Z

index.html

+          values are their corresponding theme overrides.
+        </p>
+        <p>
+          A <dfn>themeable member</dfn> is a [=manifest=] member that can be


Suggested change

A <dfn>themeable member</dfn> is a [=manifest=] member that can be

A <dfn data-dfn-for="manifest">themeable member</dfn> is a [=manifest=] member that can be

marcoscaceres · 2026-02-16T04:07:18Z

index.html

+        </p>
+        <aside class="note">
+          Because the [=themeable members=] were defined prior to the
+          introduction of dark mode, they are implicitly treated as the light


Nit: link to "dark" mode?

https://drafts.csswg.org/mediaqueries-5/#valdef-media-prefers-color-scheme-dark

Maybe we should ask the CSS folks to define "dark" mode and "light" mode independently of the the value (i.e., as a concept we can link to)

marcoscaceres · 2026-02-16T04:07:55Z

index.html

+            The [=manifest/color_scheme_dark=] member's [=ordered map=] accepts
+            [=themeable members=] as keys, and their values as the theme
+            overrides.


Suggested change

The [=manifest/color_scheme_dark=] member's [=ordered map=] accepts

[=themeable members=] as keys, and their values as the theme

overrides.

The [=manifest/color_scheme_dark=] member's [=ordered map=] accepts

[=themeable members=] as keys, and their values as

overrides.

marcoscaceres · 2026-02-16T04:10:13Z

index.html

+            </li>
+            <li>Let |colorScheme| be |json|["color_scheme_dark"].
+            </li>
+            <li>If |colorScheme| is not an [=ordered map=], return.


This should be an object, no?

Suggested change

<li>If |colorScheme| is not an [=ordered map=], return.

<li>If |colorScheme| is not an {{Object}}, return.

marcoscaceres · 2026-02-16T04:14:19Z

index.html

+            <li>Let |processedColorScheme:ordered map| be a new [=ordered
+            map=].
+            </li>
+            <li>[=Map/Set=] |manifest|["color_scheme_dark"] to


I was expecting to loop over the key value pairs of the |colorScheme|, and then switching on the key to process the value. But also, we should be clear what happens when there are repeated entries. I can't recall if first or last wins... but should follow what the other processing does.

christianliebel added 2 commits January 29, 2026 19:05

Add color_scheme_dark member and themeable members

55ea5f2

Remove icons from color_scheme_dark

6a5c2fc

christianliebel mentioned this pull request Feb 10, 2026

Add support for defining a theme color for both light & dark modes (prefers color scheme) #975

Open

christianliebel requested review from Copilot, dmurph and marcoscaceres February 10, 2026 09:57

Copilot started reviewing on behalf of christianliebel February 10, 2026 09:58 View session

christianliebel changed the title ~~Add color_scheme_dark member and themeable members (colors only)~~ Add color_scheme_dark member and themeable members (colors only) Feb 10, 2026

Copilot AI reviewed Feb 10, 2026

View reviewed changes

dmurph reviewed Feb 13, 2026

View reviewed changes

marcoscaceres reviewed Feb 16, 2026

View reviewed changes

-          values are their corresponding theme overrides.
+          values are their corresponding <dfn>theme overrides</dfn>. A theme
+          override is a value of the same type as its corresponding
+          [=themeable member=] (for example, a color string for a color
+          member) and is processed using that member's existing processing
+          algorithm.

	The [=manifest/theme_color=] member is a [=themeable member=].
	The [=manifest/theme_color=] member is a [=manifest/themeable member=].

	A <dfn>themeable member</dfn> is a [=manifest=] member that can be
	A <dfn data-dfn-for="manifest">themeable member</dfn> is a [=manifest=] member that can be

	<li>If \|colorScheme\| is not an [=ordered map=], return.
	<li>If \|colorScheme\| is not an {{Object}}, return.

Comments

Conversation

christianliebel commented Feb 10, 2026 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Copilot AI Feb 10, 2026

Choose a reason for hiding this comment

Uh oh!

dmurph Feb 13, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 10, 2026

Choose a reason for hiding this comment

Uh oh!

dmurph left a comment

Choose a reason for hiding this comment

Uh oh!

dmurph Feb 13, 2026

Choose a reason for hiding this comment

Uh oh!

marcoscaceres Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

marcoscaceres Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

marcoscaceres Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marcoscaceres Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

marcoscaceres Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marcoscaceres Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

christianliebel commented Feb 10, 2026 •

edited by pr-preview bot

Loading

marcoscaceres Feb 16, 2026 •

edited

Loading

marcoscaceres Feb 16, 2026 •

edited

Loading