Summary:
When using themes that have dark backgrounds and light font colors, Storm sets the background for forms to white without overriding the font color. Thus, if the font color used by the theme is white, the form is not usable because none of the labels are visible.

Steps to Reproduce:
Select a theme such as Acquia Slate and attempt to use Storm with it.

Expected Results:
Storm forms are visible.

Actual Results:
Storm forms are not visible. Text matches background color, making them unusable.

Regression:
Tested and shown to always occur under the following configuration conditions:
Storm 6.x-1.34
Drupal 6.19
Acquia Slate 6.x-2.0

Notes:
Issue may be resolved by editing storm.css:103: background-color in tr.formgroup{}.

Set background-color to inherit to make the background of Storm forms match the background of the rest of the site, or select any other color that works with the theme's selected font. Recommended color for Acquia Slate is #444.

Recommended permanent solution is to make this configurable in storm.module, perhaps using the ColorPicker module.

Comments

macman824’s picture

macman824 commented

For other Acquia Slate users, I have developed the tr.formgroup class thusly to make it fit in nicely with the theme:

tr.formgroup {
  background-color: #444 !important;
  display: block;
  border: none !important;
  border-radius: 7px !important;
  -moz-border-radius: 7px;
  margin-bottom: 10px;
}
juliangb’s picture

juliangb commented
Status: Needs review » Active

What would happen if we just removed that rule?

I don't really want to add colorpicker functionality, I think customisation is best done by the theme.

macman824’s picture

macman824 commented

Removing that rule by deleting line 103 of storm.css would have the same effect as changing it to inherit. The problem with letting the theme handle it is that "formgroup" is a custom CSS class present only in Storm, so it is unlikely that any theme will style it. As I noted, the class is useful for making elements contained within it stand out, as I did by custom-tailoring it to Acquia Slate. However, as you noted, doing things this way runs counter to the whole concept of themes in the first place.

If we are going to delete half of the lines in the definition for the CSS class "formgroup" (the other line being an explicit setting of the border to none using !important), we might as well rework Storm to output things that would previously have been stuck in a formgroup into a more standard element, so that themes may style them at will in a sane fashion.

If no one cares about making formgroups visually pop a bit, then deleting the CSS definition for the class and allowing the theme to style it by inheritance as if it were content in any regular node works fine.

juliangb’s picture

juliangb commented

It sounds like moving from form group to whatever core or other modules uses is the best.

macman824’s picture

macman824 commented

Sounds like a plan. I will cook up a patch to do that.

juliangb’s picture

juliangb commented
Priority: Normal » Minor
Status: Active » Closed (won't fix)

This is low priority for me, so it is a "won't fix" unless a patch is submitted.