Datepicker

[Chris]

Tim Camara, Keith Rozett, Vinh since the forum software already has the datepicker plugin would it be possible to use that to create a new field type in plugin settings? Currently there is no way to allow a user to easily pick a date with the feature lying completely unused, but if I simply add a class of "date" to any <input type="text" />  using a DOM inspector then a popup datepicker automatically gets attached to the input (livequery observer?). Currently the prospects of getting native browser support for HTML5 date inputs look bleak with Opera being the only browser supporting it so unless there was some vulnerability discovered with the plugin I hope you consider adding it as an additional input type in the plugin settings UI. I think the only place it is used now is for setting calendar events.




Update:

---

PPK is a slightly outdated because Chrome now supports date inputs

[Wormopolis]

I made a feature request for this as well a couple months back. not sure where it is on the list.

[Chris]

I actually did a search before creating this thread since I was sure something as fundamental as inputting dates had to already have been requested, Sphinx however decided to present me with yet another riddle...

[Tim Camara]

I don't see why not. I'll add it to my list.

[Chris]

Tim Camara, I seem to have discovered a bug which probably isn't a high priority but thought I'd mention it anyway just to make y'all aware of it, inserting an input with type="datetime" triggers a live event listener which calls $.fn.fixDateTimeInput() to access a widget named dateTimePicker which is no longer included in the framework. From what I gather this was part of a timepicker widget but it looks like there was a decision to instead make an in-house timepicker but that reference was never removed thus causing reference errors each time such a field receives the focus or a click

//fix input types
$('input').live('focus click', function (e) {
// date input
if (this.getAttribute('type') == 'date') {
// if no input date support
if (!Modernizr.inputtypes.date) {
$(this).fixDateInput();
}
} else if (this.getAttribute('type') == 'datetime') {
// if no input color support
if (!Modernizr.inputtypes.datetime) {
$(this).fixDatetimeInput();
}
} else if (this.getAttribute('type') == 'color') {
// if no input color support
if (!Modernizr.inputtypes.color) {
$(this).fixColorInput();
}
}
});

By the way, I included that timepicker widget in a plugin but under a different namespace to avoid conflict, if you are aware of the reason I'd love to hear what about it caused a switch to using an in-house created version which could probably save me some debugging headaches down the road.

[Tim Camara]

Added the bug to our list. I tried to look up what caused the change, but I could only get as far as that the change was made on April 27, 2012. No idea why it was changed, and the people that did the change no longer work here, so the odds of anyone remembering are pretty slim.

Now if we could just drop IE8 support, we probably wouldn't need this shiv at all.

[Chris]

Firefox is being a holdout in that area as well for some reason.
Thanks once again for the info Tim!