Closed
Bug 563565
Opened 15 years ago
Closed 14 years ago
Use system colors in CSS wherever possible, instead of hardcoded colors
Categories
(Toolkit :: Add-ons Manager, defect)
Toolkit
Add-ons Manager
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: Unfocused, Unassigned)
References
Details
(Whiteboard: [rewrite])
Most colors are currently hardcoded. They should be changed to be system colors wherever possible. BUT this should be done *after* we have a finalized visual style, so we're not wasting time changing things that will just be changed again.
Updated•15 years ago
|
Version: unspecified → Trunk
Updated•15 years ago
|
blocking2.0: --- → final+
Comment 1•15 years ago
|
||
Changes here doesn't affect any theme developer, right?
Comment 2•15 years ago
|
||
It would affect them a little if they are copying our theme code as a basis, not sure if that makes it worthy of being a beta blocker or not. Since it seems the theme won;'t be finalised by beta, probably not.
Updated•14 years ago
|
Assignee: nobody → bmcbride
Comment 4•14 years ago
|
||
What is the magnitude of work here, and does it still block as the EM UI has changed a fair bit since May?
Reporter | ||
Comment 5•14 years ago
|
||
Yea, its still an issue. Its part of my ongoing work on bug 601022 - which is a lot of inter-dependent theme-related work, so I'm fixing a lot of dependent bugs (like this) at once.
Depends on: 601022
Reporter | ||
Updated•14 years ago
|
Status: NEW → ASSIGNED
Comment 6•14 years ago
|
||
Per the meeting and UX guidance we've decided that (apart from Linux where we will be using native styles for the most part) the add-ons manager appears in the content area and so need not necessarily fit in with the OS conventions as much as the rest of the UI, so this bug it really a wontfix now.
Assignee: bmcbride → nobody
Status: ASSIGNED → RESOLVED
blocking2.0: final+ → ---
Closed: 14 years ago
Resolution: --- → WONTFIX
Comment 7•14 years ago
|
||
Is this something that we woudln't fix if we had solid patches in hand? I understand it not being a priority, but it seems like something that would be useful even if it doesn't make it into Firefox 4.
Comment 8•14 years ago
|
||
(In reply to comment #7) > Is this something that we woudln't fix if we had solid patches in hand? I > understand it not being a priority, but it seems like something that would be > useful even if it doesn't make it into Firefox 4. The problem is that the system colours available to us in CSS don't really match with the UI stylings that we want to do, it's more of a "cantfix without degrading the UI" than a wontfix
Comment 9•14 years ago
|
||
OK. Thanks for the follow-up. That makes sense to me and the resolution seems good considering that.
Comment 10•14 years ago
|
||
Has anyone checked how the chosen colors interact with changes to modified theme colors. One thing I have seen happen with Firefox and other Mozilla applications is that custom colors are chosen that work well / ok with the default theme colors but if the default colors are changed the custom colors fail badly.
You need to log in
before you can comment on or make changes to this bug.
Description
•