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.

jQueryUI Date Picker CSS Overridden

  1. jaredcobb
    Member

    Hi there,

    I happen to be using a jQuery UI date picker in my page styled with a jQuery UI theme... And I've also got a Gravity Form on the page. My Gravity Form doesn't use a date picker, but I am loading the Gravity Forms 'form.css' file.

    Because the form.css is loaded after my jQuery UI css, and because the form.css selectors aren't targeting a child of '.gform_wrapper', the form.css is styling my own date picker and overriding the jQuery UI theme I'm trying to use. (See lines 574 - 728 of form.css in version 1.6.2.11)

    Would it be possible (in a future release) to more specifically target the jQuery UI date picker in your form.css by doing selectors such as:

    .gform_wrapper .ui-datepicker-div { }

    instead of just

    .ui-datepicker-div { }

    I'm using the Google CDN to load my jQuery UI css so I can't modify it... I don't really want to override the CDN copy in my style.css to throw !important on those styles or more specifically target my own date pickers (defeats the purpose a little)... And I don't want to necessarily edit my local copy of form.css (for upgrade reasons).

    Any chance that might be possible? Thanks!

    Posted 12 years ago on Saturday January 28, 2012 | Permalink
  2. Yes, I initially had the CSS set up that way and it ended up breaking things for some reason. If I recall it's because the element is dynamic and doesn't actually reside in the .gform_wrapper div when it's rendered. I'll be happy re-visit the datepicker CSS and see if I can fix it up for you for the next release..not sure but I'll give it a fresh look.

    Posted 12 years ago on Saturday January 28, 2012 | Permalink
  3. Yeah, it's not a child of the .gform_wrapper so it's going to be difficult to restrict it with just CSS inheritance. Here's the current path to the datepicker div as rendered in the browser.

    [css]
    html.wf-myriadpro1myriadpro2-n6-inactive body.page div#ui-datepicker-div

    I'll play around and see if I can come up with something but I'm not sure what I can do offhand. What you CAN do is disable the default forms.css file and copy all of those styles to the end of your theme stylesheet. You can modify that version then without worry of it being overwritten. Of course, you'll need to keep up with what's new in the default stylesheet but.. that would work for you.

    Posted 12 years ago on Sunday January 29, 2012 | Permalink
  4. jaredcobb
    Member

    Ah hah! I see what you mean. I didn't inspect the element and assumed jQuery UI just injected it inline.

    So I did some digging and came up with a possible solution if you're interested. I added the following lines to /js/datepicker.js starting on line 31:

    var addCustomClass = function(input, instance) {
        instance.dpDiv.addClass('gform_datepicker');
    };
    
    element.datepicker({ yearRange: '-100:+20', showOn: showOn, buttonImage: image, buttonImageOnly: true, dateFormat: format, beforeShow: addCustomClass });

    The Date Picker object accepts a setting hook called 'beforeShow' in which they pass you the datepicker instance. The callback function (addCustomClass) is executed before the Date Picker is opened. I'm doing an addClass() on the parent div. This should allow for targeting the gravity form styles more specifically.

    I think I might go ahead and do that to my plugin locally, and just take notes for myself to remember to edit that upon any upgrades... Unless of course you like the solution and want to integrate it into a future release.

    PS - Gravity Forms rocks, it's saved me a ton of time in coding!!!

    Posted 12 years ago on Sunday January 29, 2012 | Permalink
  5. Cool. Thanks for that. I'll mention it to the rest of the team and see if that's something we can get implemented. I think it's reasonable and adds an extra bit of flexibility. We always like that.

    Posted 12 years ago on Sunday January 29, 2012 | Permalink
  6. jaredcobb
    Member

    Awesome! I also updated and tested the CSS. I used a pastebin if you want to grab that too:

    http://pastebin.com/jKHcZEvE

    *Note that in the newest version of the jQuery UI CSS themes (1.8.17) for some reason they're doing a display:none; on the ui-datepicker class (which is the calendar table). So in that pastebin you'll see on its line 94 I've added a display:table. It shouldn't mess with older versions of jQuery UI CSS since that table needs to be disaply:table; when it's rendered anyway.

    Thanks!

    Posted 12 years ago on Sunday January 29, 2012 | Permalink
  7. Cool. Thanks. Hat tip to you sir.

    Posted 12 years ago on Monday January 30, 2012 | Permalink

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