On 1/20/14 8:04 AM, Marc Delisle wrote:
Hi, Please have a look at [0]. The issue is about input type="date". This gives a nice date validation in Chrome, but blocks Chrome users from pasting dates.
I suggested to keep this input type but add a checkbox so that a user can revert to input type="text".
Comments?
My vote is to optimize the page for each browser; Chrome gets a "text" field and other browsers get "date". My second choice is to revert this field to input type "text" should the "different versions for different browsers" implementation be problematic.
Reasoning:
1) I'd prefer to avoid adding the checkbox; it is reasonable but my preference would be to solve (or workaround) the problem in a way that doesn't add more complexity to the user. Adding the checkbox means we've cluttered the user interface for an option that most users won't change regularly (as in, they may set it once, but won't flip back and forth).
2) The date type is designed so browsers can present an optimized interface. Chrome's seems to be broken (because it prevents copy/paste) and we can't expect them to fix it, so we should work around it while preserving the correct type for other browsers.
3) We already have the datepicker, so allowing the browser to also show their own date picker is redundant; most browsers don't yet implement this functionality so I don't think it takes anything away from the user by keeping it as "text" and forcing them to use our datepicker. They don't lose functionality.
We may elect to perform client-side date validation on this field[1], but in general we don't do much validation anyway[2].
1 - The rules of date validation can get rather complex with regards to leap years, leap days, missing days, and so on. How thoroughly we want to check a date is another matter entirely.
2 - Several months ago I added a related item to Marc's "Interface Improvements" GSoC project for "Improved notification when attempting to insert invalid data", so this may be improved soon.