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?
[0] https://sourceforge.net/p/phpmyadmin/bugs/4218/
Hi
Dne Mon, 20 Jan 2014 08:04:34 -0500 Marc Delisle marc@infomarc.info napsal(a):
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".
How about using input type="text" and adding pattern="[\d]{4}-[\d]{2}-[\d]{2}" to do the client side validation (this is just a not tested example)?
Adding checkbox sounds like a bad idea to pollute user interface.
Michal Čihař a écrit :
Hi
Dne Mon, 20 Jan 2014 08:04:34 -0500 Marc Delisle marc@infomarc.info napsal(a):
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".
How about using input type="text" and adding pattern="[\d]{4}-[\d]{2}-[\d]{2}" to do the client side validation (this is just a not tested example)?
In Chrome, 'input type="date"' does more than that; for example, you cannot enter the month '13'.
Adding checkbox sounds like a bad idea to pollute user interface.
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.
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.
Le 2014-01-20 10:38, 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.
- 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.
Let's remove the 'input type="date"' because it's not cross-browser and causes unwanted side effects as in bug #4218.
GSoC's project should improve our situation in this regard.
Marc, Then you can add my patch for the time being.
Viduranga Wijesooriya
On Wed, Jan 22, 2014 at 10:59 PM, Marc Delisle marc@infomarc.info wrote:
Le 2014-01-20 10:38, 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.
- 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.
Let's remove the 'input type="date"' because it's not cross-browser and causes unwanted side effects as in bug #4218.
GSoC's project should improve our situation in this regard.
-- Marc Delisle http://infomarc.info | http://phpmyadmin.net
CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.cl... _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Le 2014-01-22 07:33, Viduranga Wijesooriya a écrit :
Marc, Then you can add my patch for the time being.
Viduranga Wijesooriya
Viduranga, no, it will be cleaner to just remove the 'input type="date"'.
On Wed, Jan 22, 2014 at 10:59 PM, Marc Delisle <marc@infomarc.info mailto:marc@infomarc.info> wrote:
Le 2014-01-20 10:38, 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? >> >> [0] https://sourceforge.net/p/phpmyadmin/bugs/4218/ > > 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. > Let's remove the 'input type="date"' because it's not cross-browser and causes unwanted side effects as in bug #4218. GSoC's project should improve our situation in this regard. -- Marc Delisle http://infomarc.info | http://phpmyadmin.net ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net <mailto:Phpmyadmin-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-- Best Regards Viduranga Wijesooriya
CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.cl...
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel