-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New feature proposal: add support for media
attribute to <meta name="theme-color">
#6495
Comments
This seems somewhat reasonable, but I suspect it'd be better to approach this holistically as part of making all the app manifest properties (such as screenshots, background color, splash screen, etc.) color-scheme aware. So I suspect this would best be tackled by opening an issue at https://github.com/w3c/manifest/. Then Additionally, please note https://whatwg.org/faq#adding-new-features : it's best to start with a use case, not a solution. In this case your use case appears to be dark mode vs. light mode, so that points toward something less general than the full power of media queries. |
This is something we are very interested in, as implementors. @dcrousso is a browser engineer. It would be good to make all the app manifest properties color-scheme aware. But it also makes a great deal of sense to provide a mechanism for developers to define a theme color for both dark and light modes using the lightweight Most websites are not “web apps” and do not have a manifest file. Requiring a manifest file to define a dark mode theme color while supporting light mode theme color in HTML does not make sense. Rather than punting on this, we'd love to have a discussion about what syntax might be best. |
Also, unless I'm misreading this
that seems to suggest that the I'd also like to avoid having situations where network latency causes there to be a color change flash (see the example I describe in the issue description above). |
I like this proposal. In most cases I would not want to add an entire manifest just to handle basic theme issues like light/dark mode. If I had a manifest anyway, that would be fine - but I have many sites & apps using color themes without needing a full manifest. In fact, I don't know how to use a manifest, but I do understand how to use this meta-tag with media queries after a quick glance.
I do think @domenic hints at an important question about which media queries are allowed? Are we talking about a limited set of color-related preferences, or all media queries? And what are the use-cases?
|
Are there any issues with adding Another thing I'm curious about is the evaluation of other non- In principle, I'm all for this, and I think it'd be a great addition to the platform. |
I think one of the big questions at hand is — are |
I think the consistency of |
While using But whichever way you go, if you're going to apply media queries syntax, then allow the full set of queries. Limiting it seems unnecessary, and probably means making special exceptions just for |
It seems fine to extend (And speaking of web manifest, I think #6444 was a mistake as per mozilla/standards-positions#500 and web manifest should instead tackle media considerations on a per-feature basis, as this proposal does.) |
While I expect that color-scheme would be the most common reason to change this, the contrast MQs are also relevant, letting you flip to a more consistent color for While most of the existing MQs wouldn't be particularly useful here, there are enough of them that a bespoke mechanism reproducing a subset of them seems like a waste of time and spec complexity. We've already got a mechanism for expressing and selecting based on user preferences, so we should just reuse it.
Yup, several of those properties should be MQ-aware as well (for the same reasons as above, not just color-scheme-aware). That looks like a problem that would be at least slightly more difficult to solve (refactoring the syntax of the manifest object) vs applying the |
I gave a go at writing a PR for this in #6569. I'm sure I missed plenty of nuance from the conversation here; please take a look and help me fix it! :) |
This might well be a silly question but I figured I'd ask anyway... From an implementor perspective, how hassle-ish would it be to parse the value of the I know that would mean that the value wouldn't resolve until style sheets have been loaded and parsed, but that's also true of the background colour of the document so in theory everything should resolve at the same time (unlike the discussion around the web app manifest which might be fetched and parsed asynchronously). The use case here—which, I admit is very niche—is having a single site or document with multiple stylesheets (each one potentially having its own light and dark mode). The other use case is when the theme colour changes to match the content of the page (Jen showed the example of an e-commerce store that updates the theme colour based on the colour of the item you're looking at). That's currently possible using JavaScript in a kind of brute-force way (updating the DOM node of the meta element to change its |
Can't you just do the following: <link rel="stylesheet" media="(prefers-color-scheme: dark)" href="dark.css" />
<link rel="stylesheet" media="(prefers-color-scheme: light)" href="light.css" /> This will on-the-fly swap the applied CSS when the color scheme changes. The idea is to enable the same for |
That wouldn't solve either of the use cases I mentioned. Sorry if I wasn't clear: I wasn't talking about a site having two stylesheets, one for dark and one for light. I was talking about a site having many, many stylesheets (in a Zen Garden kind of way). On my site, for example, I have multiple style sheets for different theming and each one might have it's own media queries for dark and light mode. And for the situation where the theme colour changes to match the contents of the page, JavaScript is currently the only way to do it (that's unrelated to dark and light modes though). |
Oh, I see. You mean schemes not exposed by a media query. So you could have a "summer" scheme (whatever that may look like), which has a dark and a light variant. Gotcha. Yeah, in this case you need to JavaScript it. |
The current spec for obtaining the page's theme color allows for only one color value to be "returned" for use by the user agent. This means that there's no declarative way for a developer to adjust the theme color of their site depending on the state of the user agent or display device. This results in situations where the site only looks good when the user agent state or display device initially matches what's expected by the page. As an example, if the page assumes that light mode is the initial/default state and the user has already enabled system-wide dark mode, then the theme color could be painfully bright and would contrast/conflict with the rest of the system.
It would be great for developers (and also possibly web crawlers) to be able to have
<meta name="theme-color">
support amedia
attribute similar tolink
. For example,As far as compatibility, the algorithm for obtain the page's theme color is a "first pass" system which will return as soon as a valid
<meta name="theme-color">
is found in tree order. Since this feature is entirely opt-in, it's possible for a developer to preserve the existing behavior of something likeby making sure that it is the first
<meta name="theme-color">
in tree order and have any alternates come afterThe text was updated successfully, but these errors were encountered: