Weird style behavior.... « Gravity Support Forums

Gravity Support Forums » Plugin Support » Gravity Forms

aemillerco
Member

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.

http://www.customseedpacks.com/order/

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!

Thanks!

Posted 13 years ago on Tuesday June 14, 2011 | Permalink

The background color is coming from a rule on line 88 of the dynamic.css file.

http://www.customseedpacks.com/wp-content/uploads/pagelines/dynamic.css?ver=135-06141151959

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.

[css]
#feature-footer,
.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 table.forum th,
#grandchildnav.widget,
blockquote,
input,
textarea,
.searchform .searchfield,
.wp-caption,
.widget-default,
.commentlist .alt,
#wp-calendar #today,
#buddypress-page div.activity-comments form .ac-textarea,
#buddypress-page form#whats-new-form #whats-new-textarea,
.post-nav,
.current_posts_info,
.post-footer,
#twitterbar,
#carousel .content-pad,
.success,
.sf-menu li li,
.sf-menu li li,
.sf-menu li li li,
.content-pagination a .cp-num,
.hentry table .alternate td {
	background:#198a00;
}

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 13 years ago on Tuesday June 14, 2011 | Permalink

aemillerco
Member

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 13 years ago on Wednesday June 15, 2011 | Permalink

Kevin Flahaut
Administrator
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..
```
[css]
#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.
```
[css]
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 13 years ago on Wednesday June 15, 2011 | Permalink