Isaac Bennetch a écrit :
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:
- 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).
- 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.
I have not seen other browser presenting an optimized interface for this, so I'm not sure how they would react when they start to support this HTML5 feature.
- 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.
The datepicker is optional, but the validation enforces correct date when typing.
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.
We already have date validation when the user exits the input field; for example, enter "2014-14-01", exit the field and it becomes red. But the incorrect date stays there and can be submitted (will be rejected at the MySQL level).
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.
Right.