Something strange afoot, here:
An instance of Datepicker is showing up in a weird place as a single bar in the upper left hand corner of this page.
I'm using both jQuery UI's Datepicker and Accordion on a page. In the CSS for the UI, the display:none
for Datepicker seems to be overridden by the display:block
for the Accordion, at least according to Firebug (see img below).
Then, once the Datepicker trigger is clicked in the 'catering/event room' tab (click one of the buttons to show div with Datepicker,) the display:none
seems to then work.
Here's what the bad div looks like:
and here's the Firebug panel:
I had the same problem and while some of the above solutions work, the easiest fix of all is to add this to your css:
#ui-datepicker-div {display: none;}
This basically hides the realigned datepicker element when it cannot be binded to an existing invisible element. You hide it, but it will be initialized again when you click on an element that needs to display the datepicker. Upon re-initialization, the datepicker element with id #ui-datepicker-div
will have the correct position.
In my case, I use the session "$(document).ready(function(){" of JQuery in my favor.
As I have a JavaScript file that is loaded in all pages of my system, I just added the following line on it.
$('#ui-datepicker-div').css('display', 'none');
For me, it appears a clear and elegant solution because I did not have to change its library.
Best of all, it is working fine on all browsers. :)
The problem could be that you're binding the datepicker to something that is not visible, that would explain the odd positioning (trying to offset from something that doesn't exist will degenerate to offsetting from (0,0)). The datepicker <div>
should have at least a table inside it so maybe the datepicker is getting confused and throwing an exception before it finishes initializing itself. When you click on one of the bound inputs, it is probably initializing itself again (or at least properly finishing the initialization) and everything works fine after that.
Try binding the datepicker when the date input becomes visible:
$(".date_picker").datepicker({ disabled: false });
id="cater"
to <input type="text" name="cater"/>
$('#cater').datepicker();
when the "reserve event room" button is pressed.If that works then you'd have to add similar hacks for other datepickers. If it doesn't work then I'm probably wrong. If my guess turns out to be right then you might want to report a bug to the jQuery-UI people.
BTW, in Safari I can only see the first two tabs, I had to switch to Firefox to see the "catering" tab. Oddly enough it works just fine in Chrome. This is probably unrelated but I thought I'd let you know anyway.
The problem is down to the element the datepicker is being binded to not yet being available.
The solution I found was to initalize the datepicker when the actual element has been clicked and then showing it straight after initalization. This ensures the element is available before the datepicker has been binded to it and initalized.
$(function() {
$(".date_input").click(function() {
$(this).datepicker();
$(this).datepicker("show");
});
});
....
<input type="text" class='date_input' />
I had a similar problem in Chrome and I solved it editing jquery-ui1.7.2.custom.css
from:
.ui-helper-hidden-accessible { position: absolute; left: -99999999px; }
to:
.ui-helper-hidden-accessible { position: absolute; left: -9999999px; }
There's probably too many nines for Chrome.
Try moving the last block to the bottom of the page (right before you close the body tag). You can read more about why you want to do this here:
http://webdevel.blogspot.com/2008/09/place-javascript-code-at-bottom-of-page.html
BTW: Cool idea for a menu. I like it.
Sometimes it has to do with the z-index of another item on the page being higher. Setting the z-index to a very high number solved my issue.
#ui-datepicker-div {z-index:11111;}
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With