-
Notifications
You must be signed in to change notification settings - Fork 162
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
A means to control the "theme color" #225
Comments
Please, whatever decision is going to be taken on this topic, keep in mind those points... Both status bar and native control customizations have impact on app ergonomics A difference I often see between native & web apps is that one mostly rely on the system design and ergonomic rules (not all of them but still...), while the other wants to "dictate" its own rules which can be either better or a complete nightmare. Windows / Windows Phone ergonomics are very different from MacOS / iOS ones or Linux / Android ones and so on... OS Ergonomic rules give Users the power to immediately know how to use most of the interfaces of any apps they install on their system and to be productive with them. In browsers, ergonomics and design of native controls are per browser instead of being per OS, but, to have more extended possibilities, Web App developers / designers often decided to prefer home made widgets instead of native controls with a sad impact on accessibility too as only very few of them applied ARIA guidelines... I think we need to motivate Web developers to use more and more native controls which can provide native better accessibility, better performances, lighter required code and memory footprint (with impact also on battery), and of course, more intuitive interfaces for the user. The only way I see for that is to give the developer and the designer more possibilities to interact with such control but such interactions should still have their limits to not break those controls benefits In this regard, on the design topic, I appreciate the apple-mobile-web-app-status-bar-style approach by proposing a limited set of variants that should still be valid when there is some OS updates with potential new designs. The Apple values set for the status bar is probably too limited for native controls (and maybe even for the status bar) but I think this is going to the right direction |
The use case for this was not well suited to the manifest. It's solved by meta theme-color instead. |
Support for theme-color landed in Chrome 39 in Lollypop. I'm still wondering if theme-color could be useful in the manifest if it served as a "default theme color". This would still allow individual pages to control their own theme color dynamically if need be, but then always fall back to the default theme color defined in the manifest. http://updates.html5rocks.com/2014/11/Support-for-theme-color-in-Chrome-39-for-Android |
@marcosc I'm with you here, in various use cases we're crowding web pages with I'd like to see the possibility to include a "default theme color" in the manifest and if some people wish, they could override it with a maniputable |
On February 8, 2015 at 10:47:32 AM, Volker E. (notifications@github.com) wrote:
Yeah, I'd also like to add this. However, I'm want to wait a bit until we get manifest into some products. At the very least, I guess I can draft it up and just leave it sitting in a feature branch.
|
Add theme_color member (closes #225)
Why do we need theme color in the Manifest? Is anyone going to use it? It can't be used in Chrome because the theme color needs to be available at first paint and we can't have the Manifest available at first paint. What makes you think theme-color in the Manifest is better than having it as a tag? |
@mounirlamouri Thanks for clarification. Reason for color in manifest (if there weren't the first-paint issue): Cacheability & not cluttering HTML output with directives just useful on a minority of applications. |
We would like to be able to use
Yes, you would need to manage the theme color until the manifest is applied. However, once it's applied, then theme color would be available on first paint. It's not really different from, say, default orientation. |
It seems that there is enough support for it. Closing. |
When an application is launched in standalone mode (or any mode that shows a status bar), it would be nice to be able to have a way of controlling the color of the status bar.
Proprietary examples:
See also Chromium's Intent to Implement and ship: brand-color meta tag
The text was updated successfully, but these errors were encountered: