Skip to content
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

Closed
marcoscaceres opened this issue Jun 12, 2014 · 10 comments
Closed

A means to control the "theme color" #225

marcoscaceres opened this issue Jun 12, 2014 · 10 comments

Comments

@marcoscaceres
Copy link
Member

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

@tobie
Copy link
Member

tobie commented Jun 13, 2014

Similarly, background color of native controls (e.g.: Mobile Safari <input type=date>:

img_0300

@AMorgaut
Copy link

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

@marcoscaceres
Copy link
Member Author

The use case for this was not well suited to the manifest. It's solved by meta theme-color instead.

@marcoscaceres
Copy link
Member Author

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

@Volker-E
Copy link

Volker-E commented Feb 8, 2015

@marcosc I'm with you here, in various use cases we're crowding web pages with meta tags targeting just a small group of users, on the other hand trying to squeeze out every bit to make pages perform better.

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 meta tag per page.

@marcoscaceres
Copy link
Member Author

On February 8, 2015 at 10:47:32 AM, Volker E. (notifications@github.com) wrote:

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 meta tag per page.

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.

 

@marcoscaceres marcoscaceres changed the title A means to control the color of the status bar A means to control the "theme color" Feb 10, 2015
@marcoscaceres marcoscaceres added P1 and removed P3 labels Mar 5, 2015
marcoscaceres pushed a commit that referenced this issue Mar 7, 2015
Add theme_color member (closes #225)
@mounirlamouri mounirlamouri reopened this Mar 7, 2015
@mounirlamouri
Copy link
Member

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?

@Volker-E
Copy link

Volker-E commented Mar 7, 2015

@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.

@marcoscaceres
Copy link
Member Author

Why do we need theme color in the Manifest? Is anyone going to use it?

We would like to be able to use theme_color in other contexts, like for making speed-dial cells (together with the icons).

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.

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.

@mounirlamouri
Copy link
Member

It seems that there is enough support for it. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants