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.

Fun with css class definitions.

  1. Here is my issue: I am using a theme with customized css for your div tags. I would like to know which file I need to look at to add my own div tags to the form page output. In this instance, the file which inserts "div class=gfield_description"

    My issue is I revised the themes css file (line 244) for this div class: .gfield_description {
    float:left; margin-top:-14px; But I needed to make another class for the form field just above my submit button.

    So I made another class (Line 245) .gfield_name_box { float:left; } . I entered exactly in the form field section of CSS Class Name: gfield_name_box I entered no dot or hash tag. Then I even tried with both, but I got the same result.

    When I used FireBug, to review, the css class being picked up was still .gfield_description. And not gfield_name_box. Therefore I was not able to use this feature.

    Please advise. Life shouldn't be this hard, right? That's what the CSS Class Name text box is for.

    So two points, the obvious feature, and what file are the div tags being created from? I tried combing through your code for the past several hours with Adobe Dreamweaver CSS to no avail. I found the tag, but not where I could use it.

    If I knew what file was creating the div tags, then I could at least add my own and get by the CSS Class Name feature. For your reference, the form url is http://edmontonapartmentsrent.com/rental-search/ And the issue is the description over lapping the last form field box.

    For you to see it, you have to select one of the radio buttons inthe field titled, "# How should we address you?*" Then it will show up.

    Thanks guys.

    Posted 11 years ago on Sunday October 10, 2010 | Permalink
  2. Your CSS class name is being applied properly. There's no need to try to edit any files to inject any additional markup. Besides, if you edit any of the core files, you're creating a problem when you auto-update the plugin. Those files will be overwritten.

    screenshot

    The reason you're not seeing anything different is because the <li > with the "gfield_name_box" is already floated left.

    What exactly are you trying to manipulate? The containing list item, the input or the description?

    Also, the problem with the last description overlapping is the negative margin applied to it. If you want to apply different properties to that one, you would simply use some CSS inheritance from the containing list item id.

    li#field_1_14 .gfield_description {margin-top:5px!important}

    Posted 11 years ago on Sunday October 10, 2010 | Permalink
  3. "What exactly are you trying to manipulate?" The description. gfield_description I had to do this for the description to be positioned on the text box titled, "What kind of Price Protection Lease do you want?*" This is why you see:
    .gfield_description { float:left; margin-top:-14px; }

    But when that worked, it messed up the description below the box titled, "How should we address you?*" So I entered into the form advanced option for CSS Class Name: gfield_name_box .

    However as you pointed out Kevin,
    <li style="display: list-item;" class="gfield gfield_name_box" id="field_1_14">

    So first, why is there a space between my CSS Class Name I entered on the form?

    class="gfield(white space)gfield_name_box"

    I then made a CSS Class in the style.css file as : .gfield_name_box { float:left; }

    And yes, I would add to this to get whatever style I wanted. In this case to compensate the way Gravity Forms appears to treat the description element differently between drop down box elements and text box elements. But I left it so you can see my errors I was having on the text box titled, "How should we address you?*". While manipulating the description entered for "What kind of Price Protection Lease do you want?*"

    My question is why is the form element not picking up my CSS Class Name, gfield_name_box? If it is, then why is the div class pointing to .gfield_description and not gfield_name_box ?

    If it did point to the CSS Class Name I entered, gfield_name_box ; I would have been able to control the description for "How should we address you?*", which is being treated differently by Gravity Forms for the box "What kind of Price Protection Lease do you want?*"

    The issue I am having is the different types of form options, such as drop down boxes verses text boxes treat the description differently as to where it will be placed. I noticed this when I selected a text box rather than a drop down when this issue occurred for me.

    I wouldn't have even made a different CSS Class Name is Gravity Forms didn't treat the description styles differently with different form options (drop down boxes verses text boxes). But it does. This is why I got into making new CSS Class Names to compensate these differences.

    I just want to have different a .gfield_description so I made a new one in the style.css file called, .gfield_name_box and then add my styles.That's what I thought the CSS Class Name override in the form advanced options was all about?

    What did I miss Kevin in the translation of what is affected using the CSS Class Name override in the form advanced options?

    I used your 5px!important in FireBug. And of course it works for the text box titled, "How should we address you?*" But then throws off the description for the drop down box titled, ""What kind of Price Protection Lease do you want?*"

    So I thought when I made my own css class, and entered it in the CSS Class Name Form option, this would pick up my new css class .gfield_name_box and apply the new styles to my description below "How should we address you?*" But it didn't. Why?

    Posted 11 years ago on Sunday October 10, 2010 | Permalink
  4. Robert,

    The reason you're not getting the expected results from your new class isn't a shortcoming of the plugin or the other CSS, it's that you're not targeting what you want to manipulate. You're adding a "float:left" property to the list item, which is already floated left. Beyond that, it's not doing anything else because you didn't specify anything else.

    screenshot

    If you're trying to target a specific description, you really don't need to add a new class in the first place. You could add a class if you plan on re-using it in multiple places but it's not necessary for one element. What you're trying to do can be done with some simple CSS inheritance from the containing list item. In your case, I viewed the source and found that the list item id is "field_1_14". So, now that we know that, we simply use that and cascade down to apply new rules to the description div that's contained within.

    #field_1_14 .gfield_description {color:#f00; margin-top:20px}

    That's just an example of how to target it, you simply apply whatever rules you want once you've targeted it correctly. By doing it this way, you only change the one instance of the description div and don't change all the others.

    It doesn't sound like you're very familiar with CSS inheritance. This is a good, easy to read article to learn more about it.

    http://www.smashingmagazine.com/2010/04/07/css-specificity-and-inheritance/

    W3Schools is a great resource to get up to speed on CSS as well

    http://www.w3schools.com/css/default.asp

    screenshot

    You'll notice from the screenshot linked above that your custom class name "gfield_name_box" IS being applied properly. The reason you're seeing a white space before it is that it's a separate class being applied to the list item. That's the correct way to assign multiple classes. When you apply multiple classes to an element, you separate them with a space, otherwise, it's just interpreted as one long class name. Class="gfield   gfield_name_box" and class="gfieldgfield_name_box" are two entirely different things. You can find information on this on multiple sites, but here's one with some decent information on the topic.

    http://www.maxdesign.com.au/articles/multiple-classes/

    As far as "treat(ing) the description differently", there are some instances where it can vary slightly (usually by a couple of pixels here and there) depending on whether the preceding element has sub-labels, etc. With the plethora of different form configurations and variety of different theme's out there, it's difficult to bulletproof the styling for every scenario. If you're seeing radical differences, I can tell you with a great deal of surety that it's inheriting CSS from your theme itself or some other plugin that's adding it's own CSS.

    I'd suggest getting more familiar with CSS, taking some time to study the form markup and then using CSS inheritance to make tweaks to specific elements. If you haven't seen it before, we do have a visual CSS guide that might help you get a better understanding of how the forms are structured and what elements have actual IDs and classes.

    http://www.gravityhelp.com/documentation/visual-css-guide/

    Posted 11 years ago on Monday October 11, 2010 | Permalink
  5. That was an excellent reply Kevin. Thank you. I like being told where I have failed so I can correct myself, lol. It must be so nice to be neo of the css matrix. #field_1_14 .gfield_description {color:#f00; margin-top:20px} You know that is the first time I have seen css make sense. "Cascading down."

    I'll take the time , thanks for putting me on a learning path Kevin.

    Posted 11 years ago on Monday October 11, 2010 | Permalink
  6. Robert,

    Thanks for the kind words. I'm happy to help all I can. Once you get in there and have those "aha"' moments a couple of times, it all starts to gel. Of course, we're here to help if you need us.

    Posted 11 years ago on Monday October 11, 2010 | Permalink
  7. In our continuing lesson css inheritance, I am stumped here Kevin. <div class=gfield_description validation_message> I don't know how to write a css line to pick up the validation_message portion of this div class. How would I describe it in my css?

    Can you explain to me how I would manipulate the validation message part of this class. I tried a few guesses, but I couldn't get the my css file to pick it up. I know I can do this, because I did this already. But I don't want to have to create a css line for every validation_message.

    So what am I missing? How can I invoke the validation_message part of this div class in my css file. So as to have the same validation style for all validation messages in my forms.

    For a real example:

    #field_1_14 .#field_1_14 .gfield_description {color:#0E4D91; margin-top: 3px; float: left;} {color:#ff0000; margin-top: 3px; float: left;}

    The above does not pick up. However this css line:

    #field_1_14 .gfield_description {color:#0E4D91; margin-top: 3px; float: left;}

    Works just fine. I am having difficulty drilling down to the specific validation_message portion of the div class. I tried underscore and a dot as well between gfield_description and validation_message.

    Posted 11 years ago on Thursday October 14, 2010 | Permalink
  8. I understand that it's a bit confusing at first.. in the actual HTML, multiple class names are defined with a space in between them and no dot (.) In the CSS file, things are defined a little differently. You don't have to specify every class on an element to add properties (although you can if you need to get very specific) and you have to make sure you cascade the id's and classes properly for everything to work.

    Okay, looking at your style.css file, I see this and it's incorrect.

    #field_1_14 .gfield_description validation_message {color:#ff0000; margin-top: 3px; float: left;}

    You DO need the dot (.) before the class "validation_message" otherwise the browser doesn't recognize that as a class name. Also, the way you're doing it, even with the dot in place, you're cascading it down as though "validation_message" is a child of "gfield_description".

    The 2 classes are siblings so that too would cause rendering problems.. the browser would try to find a "validation_message" class that's a child of the description class and since it doesn't exist, nothing happens.

    So, that said, this is how you need to format your rule to get it to work.

    #field_1_14 .validation_message {color:#ff0000; margin-top: 3px; float: left;}

    That's simply telling the browser to apply those properties to any "validation_message" class that's a child of the field with the id "field_1_14".

    If you want to apply the same properties to all of the validation message items in the form, you would need to be less specific and drop the parent ID.

    .validation_message {color:#ff0000; margin-top: 3px; float: left;}

    But, by doing it just that way, it could apply to every form you have. If you don't want that, then you'll want to cascade down based on the specific form ID itself. Something like this..

    #gform_1 .validation_message {color:#ff0000; margin-top: 3px; float: left;}

    That will apply those properties to ALL validation message classed items, but just for that one form.

    Posted 11 years ago on Thursday October 14, 2010 | Permalink
  9. #gform_1 .validation_message {color:#ff0000; margin-top: 3px; float: left;} You're a genius Kevin, lol! Okay, can you recommend an excellent CSS book I could buy and read that would explain such css coding as entering two child classes like you did?

    I can't find anything online about this. And to be able to code with CSS like you have explained, I would like to learn it all, so I can too someday be the Obi wan Konibi of the css matrix, lol!

    Posted 11 years ago on Thursday October 14, 2010 | Permalink
  10. I'm glad that helped you out.

    Any books from Eric Meyer, Andy Clarke or Dan Cederholm are always a good bet.

    Posted 11 years ago on Thursday October 14, 2010 | Permalink
  11. Thanks Kevin! Having fun now using Gravity Forms for lead segmentation!

    Posted 11 years ago on Saturday October 16, 2010 | Permalink

This topic has been resolved and has been closed to new replies.