Themes: avoid clashes with system colors

It took me a while to realize what the problem was, but it's definitely a legitimate issue. When you set the foreground color of an element the background color should be specified at the same time, you can't guarantee that the background will always stay the same color across all devices and systems.

I haven't tested this patch but it looks good. Mental, can you make sure all the other core themes get the same treatment?

I noticed that the Chameleon theme didn't have a background or foreground color on the body element, which is a big problem (the whole page changes color). I've created a new patch for this.

I also found a nice dark Ubuntu theme that I've decided to keep, however as Mental already pointed out, the d.org theme becomes much harder to use (I'm using a custom Human theme).

AFAIK this is still a problem in head

1 hunk failed.

CSS comments is not well-formatted (edit: all of chameleon's css files seem to have a non-standard formatting).

Changing the border of input fields in chameleon has nothing to do with this issue.

Thank you so much for this one - I've had no end of trouble when using user themes in Firefox that switched the colors.

Please fix this comment

+
+/*
+** Input controls
+*/

Should be

+
+/*
+ * Input controls
+ */

I think you forgot to diff the other themes in this one.

Isn't Garland the only official theme in D7 these days? Was for a moment in anycase. Well that and stark.

Let me know though.

You are right. I got confused because my checkout of HEAD still had all the old themes, but it turns out my checkout command lacked the -P parameter to prune empty folders (CVS has these quirks). Yep, they're all gone, so this is RTBC.

Cool, seems simple enough.

Committed to HEAD. Thanks! Marking down to 6.x for consideration. Needs to be ported so that it includes chameleon, etc. It's possible that one of the earlier patches is already ready to go, but someone needs to test it and mark RTBC.

@jotik, the hold-up is that in order for a bug to get fixed, it needs to a) be fixed in the latest version of Drupal and then back-ported, b) be reviewed by at least one or two people and marked "reviewed and tested by the community." This didn't happen until April 10, 2009, which explains the hold-up.

#drupal on IRC is a great place to trade patch reviews with others, make friends, and learn a whole lot. Hope you take that approach next time instead of getting frustrated. :)

Ahem. :P Moving down to 6.x for consideration. :P

Eh. Actually. I didn't initially see this, but this patch has the annoying effect of making all the input buttons white as boxes well, which is very jarring. So I've rolled this back for now, because we should figure out something else here.

FF3 Mac fwiw.

Doesn't seem like a usability issue.

That looks very tricky to solve.

I believe the nice smooth button style is a browser default (Firefox; possibly only in Linux and Mac but I'm not sure), and the background color directive overrides this default.

The only way to comply with accessibility and keep the rounded buttons may be to go the other way: Don't specify a foreground color at all. This would turn the #494949 text in select and textfields black instead of dark gray, which may look ugly too (haven't tried it out).

Edit: Or Mac, I guess. I don't remember seeing it in Windows, but it's been a while.

Here:

http://stuff.ermarian.net/arancaytar/images/drupal/background-before.png
http://stuff.ermarian.net/arancaytar/images/drupal/background-after.png

The difference between off-black and black is very subtle, but it's there if you look for it - and I predict criticism.

Isn't it really just textareas and textfields that need to have colors applied? They're simpler than other UI elements, yet they can be the most jarring when they don't match the website's template.

When a button has a gradient and rounded corners it tends to fit in with almost any context, so I'd argue that buttons and drop downs should forego color and background-color to stay consistent with the OS theme. Text fields, on the other hand, would need color, background-color and border just to be sure.

Ok, so the patch in comment 11 is no longer in core for what it's worth.

Seems that by altering the form that FF breaks the nicely formatted buttons and goes with the clunky old school ones.

Could completely theme all buttons so that they fit a Drupal look/feel.

It's the same problem as the one defined here - http://drupal.org/node/418306#comment-1475908

tagging

Tagging again

I'm marking this as postponed as it seems to be dependent on the browser. I don't have any real docs on this and I think it's a browser bug that's not well documented.

In an article by 456 Berea Street - Incomplete colors for text input fields they warn people to define neither or both the font color and background color.

We might need to move this to won't fix if there isn't a better way around this.

Doesn't seem to be a good way around this issue for now.

Ok, that's fine. Please submit a patch. This issue has seen no movement for 10 months & it didn't seem like it was a resolvable issue.

I'm tempted to close: won't fix this issue. But, let'sss move it to 8.x-dev in case some good solution is found.

The OS (or UA) is changing the background colour, it should be responsible for changing the foreground colour as well. If there was a good way to fix this, without causing other visual problems, then I would be in support of fixing in D7.

Retheming all buttons / form input controls is simply not possible for D7, but can be revisited in D8.

@jotik - I'd recommend making possible improvements with the accessibility in Drupal 7 with the Accessible Helper Module. Perhaps there's a way to work out this issue within this space so that it is tested & ready for D8.

The Garland theme has been removed from D8: #911054: Remove Garland from Core

Yup. But it's still an active problem with the code. I've just moved it to the contrib project.