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.

Enhanced user interface bug

  1. Locutus


    When adding a drop down field that uses the enhanced user interface option and is set to display only on a certain condition (field is hidden by default) the layout gets messed up as shown in the following screen shot:

    Seems like the field doesn't get it's length set.

    Would appreciate any help.

    We're using the latest 1.6 (rc4) if that matters.

    Posted 11 years ago on Saturday October 8, 2011 | Permalink
  2. Locutus

    After playing around with the form layout it seems a lot of other things are broken as well, I'm staying on the same topic because they all seem related.

    For example, when trying to set a few items with the CSS class 'gf_inline' the drop down field gets its length changed from what you've set to what I assume is the standard length for these fields.

    Screen shot:

    Using latest Chrome and Firefox.

    Posted 11 years ago on Saturday October 8, 2011 | Permalink
  3. The "gf_inline" Ready Class sets the width of the inputs/select containers to "auto" so they work inline properly.. the inputs are set to percentage widths so they inherit from that parent container width. If you target an individual container ( list item ) correctly with a new CSS rule, you can override the auto and define a specific width if you prefer. There's nothing broken there.

    I can't tell you anything specifically about your form since you only included a screen capture.

    The "enhanced UI" elements are basically divs that replace the default form select element at runtime and the widths are defined dynamically by the script. You can still view the source, grab the element ID's/classes and then redefine their width values with a few CSS rules. See my test here.

    The second select that has the "set width" was resized by adding these new rules to the stylesheet.

    body .gform_wrapper .top_label li#field_104_7.gfield.gf_inline div#input_104_7_chzn[style] {
    width: 300px !important
    body .gform_wrapper .top_label li#field_104_7.gfield.gf_inline div.chzn-drop[style] {
    width: 298px !important
    body .gform_wrapper .top_label li#field_104_7.gfield.gf_inline div.chzn-search input[style] {
    width: 260px !important

    So, if you're going to start mixing custom styles with the enhanced UI scripts then you're probably going to end up needing to tweak the layout a bit here and there. The Ready Styles are a good place to start, but they're still just generic CSS rules and aren't bulletproof by any means.

    Posted 11 years ago on Saturday October 8, 2011 | Permalink
  4. Locutus

    As you can see from the second screen shot I posted I stopped using them, with the same results.

    When attempting to submit the form I get the following layout problem:

    Posted 11 years ago on Saturday October 8, 2011 | Permalink
  5. Yep, I saw that. It's not a bug, that's intended functionality. When you use the inline Ready Class, the parent container gets resized to "auto" like I said before.. it adjusts to the content. The input is also resized to fit the content. The field width settings "small, medium, large" are overridden.

    You can see it's working fine in my test. The fields are sizing properly to fit the content.

    If you don't like the way that works, don't use the Ready Class. Create your own inline class and define the container widths to suit your preference. The world is your oyster.

    Oh, and I couldn't recreate the issue with the validation.

    It could be that you're mixing the ready classes.. floated elements ( thirds, halves, etc ) with the inline ones. Weird stuff can happen when you start mixing and matching. That's the joy of CSS.

    Posted 11 years ago on Saturday October 8, 2011 | Permalink
  6. Locutus

    The same thing happens when using the three columns ready class and one of the drop down fields is hidden by default, is that intended behavior as well?

    Posted 11 years ago on Saturday October 8, 2011 | Permalink
  7. It just depends on how it's set up. The 3 column classes are intended to work together - side by side, not necessarily with one hidden. The right one should clear the right side of the row and prevent other elements from floating into its place. If it's hidden from view, then another field could potentially float into that place.

    This is where I say again that the Ready Classes are helper CSS rules and nothing more. They're not bulletproof and it all depends on how you set up your form, order elements, mix in floated elements and inline elements. The can be affected by your theme styles as well. If you're going to be doing a lot of conditional logic and complex layouts, you'll probably need to create some custom CSS rules that are specific to your form to make everything work together the way you envision it.

    Posted 11 years ago on Sunday October 9, 2011 | Permalink