- From: Daniel Murphy <notifications@github.com>
- Date: Fri, 13 Feb 2026 10:29:32 -0800
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/pull/1207/review/3798803946@github.com>
@dmurph commented on this pull request.
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
> @@ -1497,6 +1503,78 @@ <h3>
</ol>
</section>
</section>
+ <section>
+ <h3>
+ `color_scheme_dark` member
+ </h3>
+ <p>
+ 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?
--
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1207#pullrequestreview-3798803946
You are receiving this because you are subscribed to this thread.
Message ID: <w3c/manifest/pull/1207/review/3798803946@github.com>
Received on Friday, 13 February 2026 18:29:36 UTC