Width of fields too short…

  • Resolved edit4ever

    (@edit4ever)


    8 years, 5 months ago

    Please add an option to adjust the width of the input field. The email field is too short on some wordpress templates and we have to add in custom css.

    It would be better if the css was inline with your form.

    Thanks!

    P.S. It would also be a nice option to be able to change the “Send” button text. Submit or Signup are two that come to mind!

Viewing 12 replies - 1 through 12 (of 12 total)
  • Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    Outside of some media queries, it looks like we leave the inputs to inherit from the theme as much as possible, in regards to widths. However, I will note down and file the request so we can review internally.

    Noted on the “Send” text as well. I’m not seeing any way to filter that at the moment, but that would be a good item to provide customization for.

    Agreed that there needs to be an override for field width and also for the Submit button (Subscribe is the text I’d use).

    Also, if there was a way to hide the disclaimer, that would be great, too. When putting this in a widget, it takes up too much space…

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    A touch of CSS via your theme’s stylesheets would get things going pretty quickly for an immediate solution while we work things in at a later release.

    Quick “hack” regarding the disclaimer would be a display: none;

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    Noted down an enhancement issue for the disclaimer toggle.

    Good idea, thanks. And thanks for the quick response. I assume you guys are working on a standalone widget, rather than relying just on shortcode for sidebars/footers?

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    Not that I’m personally aware of at the moment, regarding the standalone widget. I’ll also mark that down as a feature request in case it wasn’t yet.

    The problem with using CSS to customize the output of these forms is that the CT CT stylesheet is output in the middle of the document body where the form starts. That means developers like me have to put a stylesheet even later than that on the page to get my rules to run after yours.

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    Not necessarily. While that would be true for matching selectors. If you provide a stronger selector, then that one should take precedence regardless of the load order. For example, using twentysixteen has full width inputs for me. I realize not everyone is going to be using that same theme, but it does illustrate that the theme can override without any extra actions from the site owner.

    That said, the fact that the spreadsheet is loading so late is something that I will note down so we can take care of. It should not be loading so late in the page. It should be in the <head> like everything else. I suspect it’s being enqueued after the appropriate hooks.

    It ends up in the footer for me, but I can’t find anywhere in your code where CSS includes are output via the wp_footer hook. I had to use a priority of 20 to get my include after this plugin’s.

    This is how I’m including a small override stylesheet at the moment:

    function add_late_css_override() {
    echo '<link media="all" rel="stylesheet" type="text/css" href="' . get_stylesheet_directory_uri() . '/ctct.css" />';
}
add_action( 'wp_footer', 'add_late_css_override', 20 );
    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    From the looks of it, we’re calling wp_enqueue_style() at a point that’s too late to make it into the header. However, instead of trying to load another css file, I’m sticking with my recommendation for stronger selectors. IDs are notably strong in specificity with CSS.

    Continuing with my example of twentysixteen, the field is getting a width of 100% because of this selector matching the email field:

    input[type="date"], input[type="time"], input[type="datetime-local"], input[type="week"], input[type="month"], input[type="text"], input[type="email"], input[type="url"], input[type="password"], input[type="search"], input[type="tel"], input[type="number"], textarea

    At the same time, twentysixteen has a parent <div id=”primary” class=”content-area”> wrapping the contact form output, and dropping in #primary input[type="email"] { width: 100%; } it in at the end of the twentysixteen stylesheet took over. Should be completely possible to not load a custom css file so late.

    We are still looking into the late loading, no matter what I say above, but above should help ease the burden of compatibility with themes.

    OK, thanks for checking. I am not worried about the field width. My rules put the text boxes on the next line after the labels, put some white space in between the opt-in checkbox and its label, override the text colors of the labels to inherit, remove bold font weights, and hide the disclaimer and horizontal rule at the bottom of the form. 

    /**
 * Constant Contact form
 */
.ctct-form input[type="text"],
.ctct-form input[type="email"]{
    display: block;
    clear: left;
}
.ctct-form input[type="checkbox"]{
    margin-right: .5em;
}
.ctct-form-wrapper .ctct-input-container label,
.ctct-form-wrapper .ctct-form-field-text label{
    color: inherit;
    font-weight: normal;
}
.ctct-form-wrapper hr,
.ctct-form-wrapper sub{
	display: none;
}
    Plugin Author Constant Contact

    (@constantcontact)

    Closing as a known issue and being addressed in a near future release.

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘Width of fields too short…’ is closed to new replies.