Re: [w3c/manifest] Add support for defining a theme color for both light & dark modes (prefers color scheme) (#975)

> 1. I think it's important to figure out whether we're doing the light/dark thing _just_ for an active browser window (e.g. the title bar colour), or if we're intending to apply it wherever a manifest is used (e.g. in OS shelf icons). If it's the former, then I think it's tractable (but still architecturally difficult) to use a CSS MQ since that code resides within the browser. If the latter, it means we need to find a way to translate the MQ condition out into every OS. While Chrome OS is probably easier since we control it, it isn't limitless -- we don't really want to put a CSS engine into the OS app service just to calculate theme colours.

Ideally we should limit the scope to dark/light for now with the option to expand in future. In discussing with Lou & Brett, I’m convinced we can hard-code the support in lieu of bringing in the complete CSS engine.

As for the icons themselves, I am hopeful it can affect all icon instances. I do know that Windows and Mac support alternate theme icons (working on tracking down the details) so I would imagine that we could tailor the app package/representation to include those if they are defined (or create them if we’re talking SVG, which we’re actively working on, since SVG does support CSS user prefs too).

> 2. Note that "override" is already a word (e.g. `display_override`); I don't think the spelling is a problem (this isn't one of those words that can be spelled two ways, "overide" is simply a misspelling, like "referer" lol).

If we do away with the nested structure and model this on the `translations` proposal, I think it simplifies things substantially and reduces the need to even declare something an "override". We could define a single `override` object in the manifest and define its algorithm, but leave the member definitions and such to the individual implementation (e.g., `translations`, `user_preferences`). So, for example:

```json
{
  "translations": {
    "fr": {
      "name": "Bon chien",
      "description": "Une application pour chiens",
      "screenshots": []
    }
  },
  "user_preferences": {
    "color_scheme_dark": {
      "icons": []
    }
  }
}
```

In terms of processing the members of these override objects, only the allowed members could be redefined, and then within any array-of-objects members (e.g., icons, shortcuts), order would matter and devs could provide replacements for each whole object or only specific parts of an object (e.g., replacing the whole screenshot definition or only the accessible description of a `screenshot` member).

> 3. I think we need to workshop the layout of the combined translations / color scheme further, but if anything, if we want to generalize it, I would look at generalizing the top-level object. You have `translations / context` and `user-preferences / context`, and I was suggesting to rename "context" to perhaps `language` and `color-scheme` so it's clear what "type" it has. If you want to generalize it, you might consider generalizing the top-level one to just `alternatives` (for example), with `language` and `color-scheme` as selectors inside it. This would potentially open up a can of worms allowing for `alternatives` with both a `language` and `color-scheme` selector -- I'm not sure it's worth allowing for combinatorial conditions like this, so my preference would be to keep the designs consistent, but separate: `translations / language` and `user-preferences / color-scheme`.

Totally agree on generalizing (see above), but I am wondering if we need the added complexity of `translations` and `user_preferences` being an array of objects rather than an object itself, where the "context" is the key name. Could defining the override object (as mentioned above) solve the potential complexity problem here? I guess there’s still the potential that someone might have a dark/light icon with localized text somehow embedded in the icon (or screenshot), but I haven’t quite wrapped my head around how to solve for that yet.

> The main difference between translations and user preferences is that order matters for user preferences but not translations. So the translations proposal wouldn’t suit user preferences unless we rely on the JSON object being ordered (which probably isn’t a good idea as discussed earlier in the thread). I think this context/redefine proposal works well for both.

As [Thomas points out](#issuecomment-958735296), order does matter for shortcuts and I’d argue we’d want it to order for any array-of-objects where we are cherry-picking the bits to update (e.g., swapping only the accessible description on the screenshot rather than redefining the whole screenshots array).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/975#issuecomment-960222756