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

@marcoscaceres @mgiuca @tomayac I’ve begun working on the PR and had a few thoughts/questions about the best way to define the individual override items. Consider these in context of the syntax we are proposing ([above](#issuecomment-858333333)):

First, the key for the condition being evaluated could be `prefers_color_scheme` or `forced_colors` or `contrast` and so on. That feels unnecessarily verbose to spec. Additionally it would require us to sync any changes to MQ user preferences with our own spec, all of which feels more fragile overall. Standardizing the key as "`media`" and allowing the value to be any user-preference MQ defined in the MQ spec seems much more straightforward despite the potential pitfalls of having to rely on the CSS engine [as Matt pointed out](#issuecomment-853534482).

The proposed approach also suffers from being counter-intuitive because the hyphens from CSS are replaced with underscores to match the manifest spec (and JS in general). Our crawler has already found some instances where manifest members are accidentally hyphenated instead of underscored and I can only imagine this will add to the confusion. 

Second, as color overrides (or whatever we ultimately call them), we’re only looking at two override values, which would be pretty easy to spec out. If, however, we wanted to consider this in the context of some of the other overrides we’ve discussed (e.g., translations #676 as Marcos mentioned), we might consider a generic Override Item that’s something like this:

```json
{
  "condition": "(prefers-color-sheme: dark)",
  "overrides": {
    "theme_color": "#000000",
    "background_color": "#000000"
  }
}
```

I’m not saying this is the right way to go, but it would allow us to maintain a generic that we could work it into the two use cases we have now. Or we could consider subclassing it for each context, redefining the `condition` key as `media` in the case of this proposal or `language`/`lang` in the case of translations. In either case, the context would allow us to define the acceptable keys within that instance.

Even if we didn’t go the subclassing route and create distinct Color/Media Override and Translation items, using the same structure in both places might be useful.

BTW - I’m not married to the property names, just throwing out a potential approach that could streamline the spec process.

Alternately, if y’all know of specs with similar use cases that require an object to comprise a dynamic set of keys with none of them required, please point me to that so I can wrap my head around that spec’s approach.

-- 
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-865423007