20 Jan
2014
20 Jan
'14
8:04 a.m.
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/
--
Marc Delisle
http://infomarc.info | http://phpmyadmin.net
20 Jan
20 Jan
8:44 a.m.
Hi
Dne Mon, 20 Jan 2014 08:04:34 -0500
Marc Delisle <marc(a)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ř | http://cihar.com | http://phpmyadmin.net
8:47 a.m.
Michal Čihař a écrit :
Hi
Dne Mon, 20 Jan 2014 08:04:34 -0500
Marc Delisle <marc(a)infomarc.info> napsal(a):
In Chrome, 'input type="date"' does more than that; for example, you
cannot enter the month '13'.
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.
--
Marc Delisle
http://infomarc.info | http://phpmyadmin.net
10:38 a.m.
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.
10:52 a.m.
Isaac Bennetch a écrit :
On 1/20/14 8:04 AM, Marc Delisle wrote:
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.
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.
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.
--
Marc Delisle
http://infomarc.info | http://phpmyadmin.net
22 Jan
22 Jan
12:29 p.m.
Le 2014-01-20 10:38, Isaac Bennetch a écrit :
On 1/20/14 8:04 AM, Marc Delisle wrote:
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
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.
7:33 a.m.
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(a)infomarc.info> wrote:
Le 2014-01-20 10:38, Isaac Bennetch a écrit :
--
Best Regards
Viduranga Wijesooriya
On 1/20/14 8:04 AM, Marc Delisle wrote:
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.c…
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
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.
12:38 p.m.
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(a)infomarc.info
<mailto:marc@infomarc.info>> wrote:
Le 2014-01-20 10:38, Isaac Bennetch a écrit :
"text"
--
Marc Delisle
http://infomarc.info | http://phpmyadmin.net
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 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.c…
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)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.c…
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
3839
days inactive
3841
days old
7 comments
4 participants
participants (4)
-
Isaac Bennetch -
Marc Delisle -
Michal Čihař -
Viduranga Wijesooriya