Closed
Bug 1057132
Opened 11 years ago
Closed 11 years ago
[Email] Follow-up to 1041904: updated default theme
Categories
(Firefox OS Graveyard :: Gaia::E-Mail, defect)
Tracking
(b2g-v2.1 fixed)
VERIFIED
FIXED
2.1 S3 (29aug)
| Tracking | Status | |
|---|---|---|
| b2g-v2.1 | --- | fixed |
People
(Reporter: mikehenrty, Assigned: mikehenrty)
References
Details
(Whiteboard: [systemsfe])
Attachments
(1 file)
After some back and forth with UX, we settled on a slightly different color for productivity apps then the initial spec. The updated spec can be found here:
https://bug1041625.bugzilla.mozilla.org/attachment.cgi?id=8476849
Sorry about the churn.
Attachment #8477065 -
Flags: review?(jrburke)
Comment 1•11 years ago
|
||
Comment on attachment 8477065 [details] [review]
[Gaia PR] email theme revisited
r+, if that is what UX wants.
Although thinking more about this, I probably should not have put a default color in the HTML. This information should be derived from the header background color as specified in the CSS, as colors in HTML are usually not sustainable long term.
Looking at the shared headers.css, it looks like the orange used there is #f97c17. I probably should have just gone with data-statuscolor="background" for all the cards, so that a default from HTML is not used and that #f97c17 was used instead.
Also note that for other cards, like the account settings/confirm dialogs and such, the background color of the card is used, and I would prefer to not get into the habit of sprinkling specialized status bar-only colors in HTML/JS, but would prefer the tint applied in the status bar work generically based on the visible background color in the app's CSS. That seems more scalable long term, and would allow for things like theming in an easier way.
In any case, feel free to land this, these comments are more about caution on how generic this approach is, but you are likely already aware of the constraints.
Attachment #8477065 -
Flags: review?(jrburke) → review+
| Assignee | ||
Comment 2•11 years ago
|
||
Thanks for the comments James. I agree with you that we are mixing concerns when we hardcode a color value into the html. If we do decide to make the change mentioned above (ie. pulling theme from css), the only caveat is that the final color needs to match the theme color of the other productivity apps. And the reason we have to file this followup is because the system app puts a black .1 opacity layer over the statusbar, which the initial spec didn't take into account. So, if you were pulling default theme-color from css, you would probably have to take this semi-transparent layer into account to compute your default theme (as the other apps now due according to the new spec).
In any case, let's land this for now.
| Assignee | ||
Comment 3•11 years ago
|
||
Updated•11 years ago
|
Target Milestone: --- → 2.1 S3 (29aug)
Comment 4•11 years ago
|
||
[Environment]
Gaia bdc36b46ab6993065d36ea3d650b2c38abe51a0d
Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/09e070cb6917
BuildID 20140908160204
Version 34.0a2
ro.build.version.incremental=110
ro.build.date=Fri Jun 27 15:57:58 CST 2014
[Result]
PASS
Status: RESOLVED → VERIFIED
QA Whiteboard: [COM=Gaia::E-Mail]
You need to log in
before you can comment on or make changes to this bug.
Description
•