Open Bug 426179 Opened 18 years ago Updated 4 years ago

Issue console warning for hard-coded colors specified in chrome CSS

Categories

(Core :: CSS Parsing and Computation, enhancement)

Product:
Core
Component:
CSS Parsing and Computation
Type:
enhancement

Tracking

()

People

(Reporter: benjamin, Unassigned)

References

(
URL
)

Details

According to accessibility guidelines, chrome should not use hard-coded color values, but should always use colors influenced by look-and-feel. Can we issue a console warning when chrome CSS uses a hard-coded color?
Even when using a non-default theme and/or userChrome.css? I expect this will needlessly clutter my error console even more than it already is.
(In reply to comment #1) > Even when using a non-default theme and/or userChrome.css? I expect this will > needlessly clutter my error console even more than it already is. Are theme authors aware that they are violating a11y guidelines? I'd suspect not, so the warning would be useful.
Potential pre-build source check. Just marking the bug.
(In reply to comment #2) > (In reply to comment #1) > > Even when using a non-default theme and/or userChrome.css? I expect this will > > needlessly clutter my error console even more than it already is. > Are theme authors aware that they are violating a11y guidelines? I'd suspect > not, so the warning would be useful. > You mean theme authors are _not allowed_ to use just any colours they please but _must_ use only the tasteless colours defined by the default (or maybe, at some later stage, the current) OS theme? The famous "Toy Factory" theme, for instance, which I'm told kids like so much, is invalid just because it uses bright yellow and orange backgrounds rather than plain grey? Sheesh... If someone has difficulty distinguishing one theme's colours, after all, he can always use a different theme, can't he? Here's what I read under http://developer.mozilla.org/en/docs/XUL_accessibility_guidelines#Color : Color Color is an important tool. Different colors can give different meanings to objects and text. However, color alone is inadequate for conveying meaning or information to the user. Some users, mainly those who are colorblind or blind, will not be able to discern certain colors. Some users may override the default color scheme of your application. Color should only be used to enhance the meaning of an object or text after that meaning is also communicated another way. Not a single word about it being forbidden to use non-OS colours, especially in third-party Mozilla-product themes. And what about the userChrome.css which I write myself for my own use and no one else's? If I can see these colours and tell them apart, and if I like them, isn't that all they need to be? The day there _is_ a real error, I'll have a hard time searching my Error Console for all the needless "Hard-coded color, file ~/.mozilla/seamonkey/nexrdon9.default/chrome/userChrome.css, line: xxx" messages (plus those for my favourite theme) getting in the way. (I give user-defined backgrounds to my tabs according to whether they are: not yet displayed, already displayed, current, current on mouseover, non-current on mouseover. This means every move of my mouse over the tab bar would generate more useless clutter in the Error Console.) If ever you enable these warnings, please, PLEASE, make them dependent on some pref (and disabled by default, so you can turn the messages on when hunting for hardcoded colours in the code, and leave them off when investigating something else).
At what point did I say they wouldn't be allowed to do so? I merely stated the the warning would be useful to inform folks that they might be violating a11y guidelines.
sdwilsh, I don't think this warning would be useful for theme designers. How else would you go about creating a custom visual theme than by altering colors? It's impossible to create a comprehensive theme while adhering to accessibility guidelines. Most of the themes use hard-coded colors and they do it for a good reason. Users are free to choose the ones which they themselves find accessible. By the way, once you hard-code one color, it's actually good practice to hard-code the rest of them too (e.g. if you hard-code text color, you should do it with the background too). In some cases these warnings would flood Error Console to the point of making it useless for chrome debugging, because they would obscure other warnings which designers actually care about. I even wonder if there would be performance hit from throwing hundreds of warnings while opening a window.
You seem to be making the assumption that all third party themer's want to use hard-coded colors because the system colors aren't sufficient. I'm merely playing devil's advocate here...
(In reply to comment #1) > Even when using a non-default theme and/or userChrome.css? I expect this will > needlessly clutter my error console even more than it already is. > It seems like the colors that are violations of accessibility guidelines are the very things that theme users often want from their third-party themes, and when not, there are accessibility-oriented themes. Honestly, I don't see this info being useful to developers of third-party themes, since using your own colors is pretty much the point. Very useful to people developing the default Firefox themes though. Is there a point where the number of errors in the console becomes a performance problem? Would each violation be reported once per session, or every time a window using the violating code is opened? I like the idea of a warning, as a pref that developers can turn on, with off as the default.
(In reply to comment #8) > useful to people developing the default > Firefox themes though. And to those developing accessibility-oriented third-party themes and extensions.
Please take the discussion about the relative value of this warning, or when it should be enabled, to mda.firefox where the question about hardcoded colors was originally raised. We don't need to clog this bug, yet, especially when there's not a patch yet.
FYI the "Modern" theme shipped in SeaMonkey and Mozilla Suite has rigidly enforced guidelines that include "NEVER use system colo[u]rs". This will generate a lot of noise for SeaMonkey developers working on the Modern theme.
Benjamin, the discussion in mda.firefox is Firefox specific. This bug is in Core and affects non-Firefox applications as well.
Just to clarify, when I wrote the post about this on mozilla.dev.apps.firefox (http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/031592d86ff95f0d/e7bf8b489ddef681#e7bf8b489ddef681), I was only referring to the default themes that Firefox ships with, particularly winstripe and gnomestripe, since OS X achieves an accessibility mode for low vision users at the graphics layer with Quartz this is less of an issue for pinstripe. Instead of a console warning, which will clutter an interface exposed to end users who are using a third party theme, what about a compile time warning, or a console warning that is only displayed when a pref is set (but that pref is off by default). The core issue is that we need a way for the developers working on default themes to know that they have included a hard coded color in chrome.
Sounds like something suitable for a script running as a test - if you check in a hard-coded colour (e.g. #FF8000) then the tree turns orange. Anyway, here's a link to some of the more obvious ones.
URL: http://mxr.mozilla.org/seamonkey/sear...
(In reply to comment #14) > Sounds like something suitable for a script running as a test - if you check in > a hard-coded colour (e.g. #FF8000) then the tree turns orange. What about "yellow", "green" -- or "tomato"? Shouldn't you search not only for #xxx, #xxxxxx (where ixes are hex digits of course), but also all color names in rgb.txt? (and if you search for "color" you won't get "outline: 2px solid red" or similar)
(In reply to comment #15) > (In reply to comment #14) > > Sounds like something suitable for a script running as a test - if you check in > > a hard-coded colour (e.g. #FF8000) then the tree turns orange. > > What about "yellow", "green" -- or "tomato"? Shouldn't you search not only for > #xxx, #xxxxxx (where ixes are hex digits of course), but also all color names > in rgb.txt? (and if you search for "color" you won't get "outline: 2px solid > red" or similar) There's a perls script in bug 277717 that seems to do that.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.