Concerning the client/server side validation of the date: My approach has always been, and will always be, that while client-side validation is convenient for the user, you should always validate server-side too, and be prepared to handle any errors generated there. Never rely exclusively on client-side scripts for data validation.

Same here. Please bring back the clear button! Any workarounds? Thanks.

I think its a little ridiculous that the jQuery UI people don’t think its necessary.

Its a common use case I’ve seen many many times: The server requires dates in a specific format. So the field is set to read only, forcing the user to use the date picker. But once they select a date they can’t clear it! I am having issues now in several areas of our site because user’s can’t clear the date. We have many search forms that use dates, sometimes they put in a date but later want to pull it out after doing several searches. Right now they have to refresh the whole page, loosing all their other search criteria.

I’m posting here because I rather not create an account to login over there. Kindly add my comments if you add a wiki comment.

I’m here today because I’m looking for a date picker with a clear button and found your site. Currently I have pages with a separate button/icon to clear the date. It looks fine on those pages, but now I will have to make the icons smaller for pages where the icon should be the size of the date text. It could be a non-issue if the date picker allowed the user to REMOVE a date picked in error while maintaining validated entries for correct dates.

Allowing the user to click into the field to clear the text is a fine thought, but it also allows them to input dates in a format I do not want; or totally invalid dates unless I add client-side validation.

I use read-only text fields so that the user can’t enter an invalid date. If you go to http://jqueryui.com/demos/datepicker/ you can enter an invalid “date” like 444/44/444444 and tab out of the field. Read-only saves client-side date validation. (Actually on some pages, I don’t even display a text field. It looks like normal text; then you double-click on it; then a calendar appears then a date is selected (I wish it could also be cleared); when the calendar closes, the text looks like inline normal ([read-only] date) text again.

My workaround seems to be that I will have to provide smaller icons. Their goal seems to be visual clarity (which I think is better placed in the large popup calendar than inline with a small or oversized icon). I’ll just be helping the Optometrists.

As for having datepicker attached to a readonly input, that was a decision made by the boss who double-clicks everything (including input fields). In this particular example, the date field is used regularly to run reports from various time frames. Every time he double-clicked a date input it wold display Datepicker with the history of values entered into the field over the top. Setting the field readonly prevented the history from appearing on top of datepicker. I agree that it’s not the most elegant solution and that it’s counter to the HTML spec, but it’s sometimes harder to change user behavior than markup.

I’ll see if I can get a demo up in the next day or two.

Since buttons are no longer displayed by default in Datepicker, perhaps cancel can be added back in an option that is disabled by default? Otherwise, allowing custom buttons would be nice!

As for your use case, it is unclear to me why you would have a datepicker attached to a readonly text field. The HTML spec defines readonly inputs as those the user is not intended to edit. Similar to a disabled input, the difference being that its value is submitted with the form.

Could you explain the rationale behind having an editable widget attached to a non-editable form field? A demo page would be particularly helpful.

We removed the clear button for the reasons you quoted above, but also to remove visual complexity that can otherwise easily be done by clicking into an input and deleting the text. There are a multitude of similarly complex user behaviors that could be covered through button shortcuts, but of course the more buttons you add, the less usable the interface becomes. Perhaps in a future release, we could allow custom buttons (similar to dialog) where you could define your own callbacks to suit the needs of your app…?

You’re right, as usual Lucas.

I hope you can set them straight.