Add support for defining a theme color for both light & dark modes (prefers color scheme) #975
Comments
|
One approach that sounds good to me would be to overload Not sure if this approach conflicts with existing functionality in any way, but it's the first approach that came to mind. |
|
I don't think we can touch We may want to create a I don't have a strong preference, but I think using the last item in the list that matches (i.e. last pass) is generally easier to understand/follow (it also more closely matches the way it would be written in CSS). If this is an approach we like, perhaps we could/should do it for |
|
I'm in favor of this approach. It leaves existing functionality where it is, and extends the web manifest in a way that allows for existing or future |
|
That approach makes sense to me as well – although I might think of it as a default/shorthand, and longhand list of alternates, rather than new and legacy values. That would allow a simpler combination in the short term: Authors could also choose to provide only the default: Or (down the road) move to only using the longhand: |
|
Also see w3c/image-resource#26 where the same question is discussed in the context of |
|
+1, see my comment on w3c/image-resource#26 where I said "sure it would be great for ImageResources, but we'd also want it for the theme color". @aarongustafson FYI. We (Google) are thinking about implementing something like this in the near future (~N quarters) so having agreement on the exact format of this field in the manifest would be great. @mirisuzanne 's proposal sounds good to me. The problem it's trying to solve (not breaking backwards compat with the existing |
|
Thanks for filing this @jensimmons, It’s been on my backlog for a few weeks. We discussed this over in #955 as well. I think the piece that’s missing from the above suggestions is that multiple members may need to change based on the color scheme. My original thought was that we introduce a "color_schemes": {
"dark": {
"theme_color": "#fff",
"background_color": "#000"
},
"light": {
"theme_color": "#000",
"background_color": "#fff"
}
}Of course there’s also "color_overrides": {
"(prefers-color-scheme: dark)": {
"theme_color": "#fff",
"background_color": "#000"
},
"(prefers-color-scheme: light)": {
"theme_color": "#000",
"background_color": "#fff"
}
}or "color_overrides": [
{
"media": "(prefers-color-scheme: dark)",
"theme_color": "#fff",
"background_color": "#000"
},
{
"media": "(prefers-color-scheme: light)",
"theme_color": "#000",
"background_color": "#fff"
}
]In terms of processing, I’m not sure which would be faster to compute. We’d probably also want the first match to win if there are multiple matches. Thoughts? |
|
I like your first combined syntax, with media-conditions as keys, with nested objects. If we were matching the way CSS works, I would expect last-take-precedence when there are multiple matches - but maybe first-takes-precedence fits the existing scheme better? I don't know. |
That’s my preference as well. Not knowing the innards of browser engines, it also feels like it would be faster to process because you wouldn’t have to parse the object to determine whether you need to throw it away.
This is the confusing piece, I agree. So we have 2 conflicting paths for this stuff: In CSS proximity wins whereas in things like I’d love someone with knowledge of the perf cost to weigh in here and set me straight if I’m incorrect. |
1+ for this one, would like to see this in webmanifest |
|
Re: adding This is the kind of thing the CSSWG always avoids. It's very confusing for developers to have remember whether or not there's an 's' at the end — and that the version with the 's' works differently than the one without. This is especially true for folks who don't speak English fluently or at all, which is an incredible number of developers. An entirely different name is much better, like |
|
100% agree with @jensimmons on the naming stuff above. Could @mgiuca @marcoscaceres @tomayac @rayankans and/or anyone else who works on internals weigh in on any perf differences between the options I outlined above. |
|
I can't see any perf differences, but I'd be inclined to go with: Just from an object creation POV. I'm personally not a huge fan of property names having a dual role. However, we will need to work out what to do when multiple media queries/features match. Last wins? first wins? Most specific wins? |
|
Hmmm..., we'd probably want to just generalize the overrides... and now I've changed my opinion about the property names, as it's clear what it's doing... "media_overrides": {
"(prefers-color-scheme: dark)": {
"theme_color": "#fff",
"background_color": "#000"
},
"(prefers-color-scheme: light)": {
"theme_color": "#000",
"background_color": "#fff"
}
} |
|
I like the elegancy of the above proposal and move my thumbs up to this: "media_overrides": {
"(prefers-color-scheme: dark)": {
"theme_color": "#fff",
"background_color": "#000"
},
"(prefers-color-scheme: light)": {
"theme_color": "#000",
"background_color": "#fff"
}
}The approach feels very familiar to how you'd do this in CSS: @media (prefers-color-scheme: dark) {
/* … */
}As an analogy, for processing |
|
Half joking... we could apply them in order: {
"background_color": "white",
"media_overrides": {
"all": {
"background_color": "green",
"name": "lolz"
},
"(prefers-color-scheme: light)": {
"background_color": "blue",
"theme_color": "#000"
}
}
}Would:
🧐 |
|
With you on the…
…part. Not sure what the difference of the For the |
Yes, we could define a list props that it applies to, and only override those (ignore the rest). |
|
Ok, so concrete proposal is now
Rough processing: For each "query" of get own property names "media_overrides":
That should provide the maximum flexibility. Thoughts? |
|
For It would be great to align the two proposals. From what I can tell, Combined, this would look like in the example below. There's some duplication with the {
"media_overrides": {
"(prefers-color-scheme: dark)": {
"theme_color": "#fff",
"background_color": "#000",
"icons": [{
"src": "/icons/icon-dark.png",
"sizes": "192x192"
}],
"shortcuts": [{
"name": "Play",
"short_name": "Play",
"description": "Play the list of podcasts",
"url": "/play?utm_source=homescreen",
"icons": [{
"src": "/icons/play-dark.png",
"sizes": "192x192"
}]
}]
},
"(prefers-color-scheme: light)": {
"theme_color": "#000",
"background_color": "#fff",
"icons": [{
"src": "/icons/icon-light.png",
"sizes": "192x192"
}],
"shortcuts": [{
"name": "Play",
"short_name": "Play",
"description": "Play the list of podcasts",
"url": "/play?utm_source=homescreen",
"icons": [{
"src": "/icons/play-light.png",
"sizes": "192x192"
}]
}]
}
}
} |
|
This is great folks! I agree that I like the syntax better where the key is the MQ. Should I start a PR on this?
Yes, I have it tracked in a bug against Just to cover all the bases, I’d suggest we try to land the |
|
While I don't have a personal preference over how this is structured, I would give some caution over using |
|
Trying to speak for developers, I think consistency is key here. I don’t think it’s a good experience for developers having to remember that for Another point that I realize now: If folks create their manifests programmatically, it’s also more convenient to be able to |
|
Yeah, hot take — I’m not sure what Instead, |
|
from my earlier comment
this actually exists right now in (i.e. check that the exact color they want to use is supported before attempting to use it) |
|
@jensimmons... great points about matchings css/html! and I know I've misspelled "override" a lot 😅, so the shorter "media" is nice for that reason too! @dcrousso, I think that's pushing it a bit beyond the use case. Worst case, you can do the supports checks in JS, then instruct either the service worker or server to respond with the particular color syntax. I'd prefer we keep things simple unless there is strong case for checking @aarongustafson, let's get a all the straw-person in place and engine buy-in (or no objections!) before we proceed with spec'ing it. If Mozilla supports adding this, I'd be happy to implement it in Gecko. @annevk or @tantek, are either of you the right people to ask about this? Or is this something we ned to get a standards position on? Appreciate your guidance. @jensimmons, @hober, similar question. We know Apple doesn't comment on future products or implementations, but would you object to this being added to the spec? Any further refinements appreciated. I think we are still unclear if we should process all the matches, or if first or last wins. |
|
Something like this seems reasonable to me and in line with the arguments put forward in mozilla/standards-positions#500 against multiple manifests (some restating much older arguments dating back to the original design of manifests). It seems small enough to me to not warrant a position. (Thanks in advance for the patch!) |
|
@tomayac wrote:
I'm not liking the duplication of shortcuts, TBH. I wonder if we can do better there... it looks like image resources should sprout at {"shortcuts": [
{
"name": "Play",
"short_name": "Play",
"description": "Play the list of podcasts",
"url": "/play?utm_source=homescreen",
"icons": [
{
"media": "(prefers-color-scheme: light)",
"src": "/icons/play-light.png",
"sizes": "192x192"
},
{
"media": "(prefers-color-scheme: dark)",
"src": "/icons/play-dark.png",
"sizes": "192x192"
}
]
}
]} |
|
Can you support css vars in the manifest? so something like ... |
Adding custom property support in the manifest would likely introduce a significant amount of complexity from a parsing standpoint and from a rendering standpoint. Where would the custom props be defined? What happens if those definitions aren't loaded (e.g., stylesheet fails to load or JavaScript fails to execute)? There's also the question of the scope for these properties in terms of where they are defined and how they apply since they aren't contextual to a specific DOM node. |
|
BTW, what about this? Don't beat me. :) This request is very similar to #892. <link
rel="manifest"
href="./manifest.light.json"
media="(prefers-color-scheme: no-preference), (prefers-color-scheme: light)"
/>
<link
rel="manifest"
href="./manifest.dark.json"
media="(prefers-color-scheme: dark)"
/> |
See whatwg/html#6444 and then whatwg/html#6502, which reverted whatwg/html#6444. |
|
As an aside, we should bring back whatwg/html#6444 ... @FluorescentHallucinogen, you are not wrong... and I agree that should be supported (HTML spec issue). However, we are going somewhat for developer convenience here. I think it does get a little unmanageable if you have to keep multiple manifest for both <link
rel="manifest"
href="./fr/manifest.dark.json"
media="(prefers-color-scheme: dark)"
hreflang="fr"
/>
<link
rel="manifest"
href="./en/manifest.dark.json"
media="(prefers-color-scheme: dark)"
hreflang="en"
/>And so on... FWIW, I'm not sold on {
"name": "Good dog",
"translations": {
"fr": {
"name": "Bon chien"
}
},
"user_preferences": {
"color_scheme_dark": {
"icons": []
}
}
}In terms or processing, It would also be strange if new icons/shortcuts appeared also in dark mode. So we would need to account for that. |
@marcoscaceres In our proposals for |
|
Hi , I came here looking for a way to add this feature in my application, so till you have a proper fix , is there a temporary way to achieve this feature for defining a theme color for both light & dark modes |
|
@immortalcodes, see #975 (comment) (i.e., right now, you need two or more manifest ... but not all (any?) browsers support |
|
@aarongustafson, discussed this internally, and we'd like to propose going back to the media queries syntax. The rationale being that, at install time, the browser should take the possible MQ user preference values and convert them statically into something the OS understands (XML or whatever). As we discussed, another issue was that we (well, me... my fault 😬) had proposed essentially creating a new query/matching language for this. Feedback I got was, "yeah... cool idea... but please don't do that"... which is fair enough. The one thing we do need to do, however, is talk to the CSS working group to see if we can solve "translations" as a user preference. Personally, I think that makes sense, as it's literally a system user preference, just like dark/light mode is. We would need to bake that into a media syntax somehow (" Also, we are leaning strongly towards simple overrides for matches (even if they are more verbose). That is, if you declare an override, and it matches, that is what comes out at the end (even if the set of items in the override is not equal to what is declared in the root). |
|
Thanks for this @marcoscaceres! I’d like to suggest we take a step back and come up with a set of principles to guide us in this effort. I have taken a stab at one such set over on the FWIW, I think the |
I was thinking:
Right, but this signal is for use outside of the browsing context. Like with changing icons based on |
|
Hi all, last week I took an action to consolidate all the solutions into a single proposal so we can evaluate the pros and cons and get a better understanding of what we are trying to do here. The result is at: #1045 Please take time to consider what is proposed there - there are a lot of "sharp edges and dark corners"! 👻 After evaluating all the different approaches, my conclusion was that building on @dcrousso's #975 (comment) proposal makes the most sense. Would like to hear your thoughts, and if we agree, we can draft something up. |
Parses the user_preferences field from the manifest and sets dark_mode_theme_color and dark_mode_background_color in WebApplicationInfo. This is based off the proposal in this comment: w3c/manifest#975 (comment) There is no explainer yet. This is the same format as the translations member. Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/Y6zNtG0f-6A Bug: 1271804 Change-Id: I9764f300159d35041323d4a1602e06ba7f80afd8 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3292905 Commit-Queue: Louise Brett <loubrett@google.com> Reviewed-by: Kentaro Hara <haraken@chromium.org> Reviewed-by: Dominick Ng <dominickn@chromium.org> Cr-Commit-Position: refs/heads/main@{#945184} NOKEYCHECK=True GitOrigin-RevId: b076313fcbacd0be2f2b663f7d16083a19555e07
|
This approach makes sense to me – "theme_color": "red", Authors could also choose to provide only the default: "theme_color": "red", Or (down the road) move to only using the longhand: "theme_colors": [ Hope it would work... |
Parses the user_preferences field from the manifest and sets dark_mode_theme_color and dark_mode_background_color in WebApplicationInfo. This is based off the proposal in this comment: w3c/manifest#975 (comment) There is no explainer yet. This is the same format as the translations member. Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/Y6zNtG0f-6A Bug: 1271804 Change-Id: I9764f300159d35041323d4a1602e06ba7f80afd8 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3292905 Commit-Queue: Louise Brett <loubrett@google.com> Reviewed-by: Kentaro Hara <haraken@chromium.org> Reviewed-by: Dominick Ng <dominickn@chromium.org> Cr-Commit-Position: refs/heads/main@{#945184} Former-commit-id: b076313fcbacd0be2f2b663f7d16083a19555e07
|
Hi there! Any resolution regarding the proposed support? I really wanted to try it out in my pwa app! Thanks you all for the amazing logical structures proposed here! |
Currently, in a web manifest file, you can define a theme color.
https://www.w3.org/TR/appmanifest/#theme_color-member
For example:
There's not currently any way to express that a certain theme color should be used for light mode, while another is used for dark mode.
In HTML, there's currently a proposal to add support for color schemes by adding a media attribute to the meta tag:
whatwg/html#6495
It would be great to be able to do a similar thing in the web manifest file.
The text was updated successfully, but these errors were encountered: