PLEASE NOTE: These forums are no longer utilized and are provided as an archive for informational purposes only. All support issues will be handled via email using our support ticket system. For more detailed information on this change, please see this blog post.

Weird style behavior....

  1. Hey guys... I am having a heck of a lot of trouble with a form that includes an "address" group of fields. I am no CSS expert so I am using stylebot for google chrome to modify the look of the form fields, and then I dump the generated CSS into the code area of my WP theme (PlatformPro).

    Look at the "state" field though. It's got a green background! I cannot figure it out.

    The only difference i see is that this field takes on a format of: #input_2_4.4 while others are #input_2_4_5 (underscore vs a period).

    I am at a total loss and going nuts over this.

    Any help would be GREATLY appreciated!


    Posted 9 years ago on Tuesday June 14, 2011 | Permalink
  2. The background color is coming from a rule on line 88 of the dynamic.css file.

    Here's the rule.. it applys a green background color to all of these elements.. including a blanket application to all inputs, textareas, etc... pretty sloppy CSS.

    .main-nav li.current-page-ancestor a,
    .main-nav li.current_page_item a,
    .main-nav li.current-page-ancestor ul a,
    .main-nav li.current_page_item ul a,
    #wp-calendar caption,
    #buddypress-page #subnav,
    #buddypress-page .activity .activity-inner,
    #buddypress-page th,
    .searchform .searchfield,
    .commentlist .alt,
    #wp-calendar #today,
    #buddypress-page div.activity-comments form .ac-textarea,
    #buddypress-page form#whats-new-form #whats-new-textarea,
    #carousel .content-pad,
    .sf-menu li li,
    .sf-menu li li,
    .sf-menu li li li,
    .content-pagination a .cp-num,
    .hentry table .alternate td {

    The best thing to do is to edit this file and remove the input & textarea references or you'll probably encounter this again somewhere else. It appears that you've overriden that blanket style with some other rules for the rest of your form. It's best to just nix it at the source than try to override it with more CSS unless you absolutely have to.

    Posted 9 years ago on Tuesday June 14, 2011 | Permalink
  3. Thanks... yea I was able to overwrite every other field, but not this one. Why is that? Here is the code:

    #input_2_4_1 {
        background-color: #FFFFFF;
    #input_2_4_2 {
        background-color: #FFFFFF;
    #input_2_4_3 {
        background-color: #FFFFFF;
    #input_2_4_5 {
        background-color: #FFFFFF;
    #input_2_4.4 {
        background-color: #FFFFFF;
    Posted 9 years ago on Wednesday June 15, 2011 | Permalink
  4. The period in the ID breaks the CSS rule. It interprets that as "do X to ID #input_2_4 that also has class .4" - That's something that's on our list to correct for the next release.

    What you could do in that scenario is use CSS inheritance to target the input based on the parent container like this..

    #input_2_4_4_container input {background-color:#fff}

    Still, in the long run, it's a lot of extra effort trying to override every input to make it white - the easier way to handle it moving forward is to simply nix the other rule. If you can't do that for some reason, you could always target all the inputs in a given form this way with one rule.

    body #gform_wrapper_2 li input {background-color:#fff!important}

    I didn't test, but the !important declaration may not even be necessary there.. the inheritance from the body tag may be enough without it.

    Posted 9 years ago on Wednesday June 15, 2011 | Permalink