Bug 29359

Summary: Add UIs for date and time types of <input>
Product: WebKit Reporter: Kent Tamura <tkent>
Component: FormsAssignee: Kent Tamura <tkent>
Status: RESOLVED FIXED    
Severity: Normal CC: bronislav.klucka, bugzillawebkit, chrisjshull, cshu, desamo, dominicc, eoconnor, eric, jonlee, luiz, manyoso, marcoos+bwo, mathias, me, mifenton, m.kurz+webkitbugs, mubatt, nhotz, paulirish, peter, sadams, spamfaenger, syoichi, thorton, tonikitoo, webkit-bug-importer, webmaster, xk1t, yael
Priority: P1 Keywords: HTML5, InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
URL: http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#date-and-time-state
Bug Depends on: 27968, 29004, 30847, 53961, 59752, 68971, 83852, 86990, 97299, 97877, 97997, 98226, 100935, 100938, 101889    
Bug Blocks: 19264, 40829    

Description Kent Tamura 2009-09-17 21:04:33 PDT
Add dedicated UIs for type=date, datetime, datetime-local, month, time, week.
Comment 1 Holger Jeromin 2010-12-14 00:33:09 PST
The code state with the simple implementation but without a UI is worse than before. 
With Javascript i can test for the support of type="date" in an input-element and disable a fancy own gui, as the browser will provide some.

Now i detect date-support in webkit, but there is no real one. In Germany the date is written like 24.12.2010, the date in html5 likes 2010-12-24. Nice for developer, but not for the user who has no clue with format he should enter.

Webkit gives no clue, that "24.12.2010" will be not accepted by the server. And i cannot help the user, as i cannot detect there is no UI.

I really hope webkit will provide a fast solution by providing a nice UI.
Comment 2 Holger Jeromin 2010-12-16 10:03:03 PST
I found a fix for the detection problem:
You can put garbage into the inputElement.value of a date input.
A browser without a UI, accepts that. A Browser with a UI changes the value to "", which is testable.
Comment 3 Chris J. Shull 2011-02-01 17:13:34 PST
This would be really nice. Is there a way to nominate?
Comment 4 Deirdre Saoirse Moen 2011-02-02 16:45:57 PST
<rdar://problem/8948907>
Comment 5 Kent Tamura 2011-02-02 16:53:33 PST
(In reply to comment #3)
> This would be really nice. Is there a way to nominate?

You don't need to nominate.  We understand the importance of this feature, and I have started to implement it.
Comment 6 Garrett Smith 2011-09-15 23:08:49 PDT
(In reply to comment #5)
> (In reply to comment #3)
> > This would be really nice. Is there a way to nominate?
> 
> You don't need to nominate.  We understand the importance of this feature, and I have started to implement it.

The buggy INPUT type=date should be removed until a suitable UI can be implemented.

The importance is not the feature, as surmised in comment 4; it is WebKit's existing buggy implementation. 

TFM:
| "User agents must not allow the user to set the value to a non-empty 
| string that is not a valid date string."
(Please read it:
http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#date-state)

As stated in comment 1, input type="date" feature being broken misleads feature tests.

Webkit type="date" is a text input with tiny spinner arrows and no datepicker.  Values are entered by the user by typing and optionally using the spinner but are not validated. The UI does not req ISO-8601 fmt. This is a spec violation. A feature check makes sure that ISO-8601 fmt is required by setting non-ISO-8601 fmt and asserting that value is reset to "". 

A shim that uses a fallback for input type=date must use the fallback for WebKit (explained in comment 2). The shim can remove the useless and distracting spinner junk that WebKit puts there by changing the input's type:

inputElement.type = "text";

When the type is reset, however, upon page refresh, the input type="date" is restored and any user input date data is lost.
Comment 7 Bronislav Klucka 2011-09-16 05:05:47 PDT
Webkit does provide informations about validity of inserted value
http://test.bauglir.com/winput.php

there is a way to use other formating as shown in my example with text field combined with pattern attribute

The problem is with the fact, that it has no gui and test for gui presence.
But with the speed gui for those (and other) elements is implemented, current spin solution is better than having no support at all.
Comment 8 Garrett Smith 2011-09-16 10:19:14 PDT
(In reply to comment #7)
> Webkit does provide informations about validity of inserted value
> http://test.bauglir.com/winput.php
> 
That's nice. But can we stick to the input feature itself and not confuse the argument by coupling `date` type with the `required` attribute? Thanks.

I linked and cited the spec for all the webkit developers. Again, Webkit has introduced a bug where there was none. Browsers have always handled unrecognized INPUT type attribute as "text". For any new HTML5 INPUT type needed, the author can use a strategy to provide a fallback for lacking native support. 

When native support is buggy, as in Webkit, there problem is much harder to solve.

(And BTW, when I click on the up arrow of your example and I see: "1582-10-15" Really useful.)

> there is a way to use other formating as shown in my example with text field combined with pattern attribute
> 
> The problem is with the fact, that it has no gui and test for gui presence.
I have an idea of what you might have wanted to say.

> But with the speed gui for those (and other) elements is implemented, 
You lost me there.


current spin solution is better than having no support at all.

You can try to read what I wrote, elaborate on why you think it was wrong, perhaps justify your own qualitative comparative beliefs (how "better"). 

As it stands, Webkit's implementation of input type="date" just creates more problems. It should be removed.
Comment 9 Chris J. Shull 2011-09-16 10:27:22 PDT
(In reply to comment #7)
> current spin solution is better than having no support at all.

How do you figure that? Not only does it look ridiculous, and is completely worthless from a user perspective, but it changes the way the input is drawn such that for a particular size there are fewer visible characters.
Comment 10 Bronislav Klucka 2011-09-16 10:50:51 PDT
(In reply to comment #8)
> (In reply to comment #7)
> > Webkit does provide informations about validity of inserted value
> > http://test.bauglir.com/winput.php
> > 
> That's nice. But can we stick to the input feature itself and not confuse the argument by coupling `date` type with the `required` attribute? Thanks.
> 
I'm dealing with the argument that it would be better to remove date and stay with text type... so yeah... let us stay with date and do not mix text there... can we both do that?


> I linked and cited the spec for all the webkit developers. Again, Webkit has introduced a bug where there was none. Browsers have always handled unrecognized INPUT type attribute as "text". For any new HTML5 INPUT type needed, the author can use a strategy to provide a fallback for lacking native support. 
> 
> When native support is buggy, as in Webkit, there problem is much harder to solve.
> 
> (And BTW, when I click on the up arrow of your example and I see: "1582-10-15" Really useful.)

I am not justifying any bug here, if there is parsing bug, lets fix it... no need fore type removal... not having GUI is not a bug... 

> 
> > there is a way to use other formating as shown in my example with text field combined with pattern attribute
> > 
> > The problem is with the fact, that it has no gui and test for gui presence.
> I have an idea of what you might have wanted to say.
> 
> > But with the speed gui for those (and other) elements is implemented, 
> You lost me there.
I've lost you? For some reason it's taking webkit team quite a long time to implement gui for date like inputs, color inputs, datalist etc. But I see no point for removing element that do behave (if there is not bug) according to spec. just because GUI is missing


> 
> 
> current spin solution is better than having no support at all.
> 
> You can try to read what I wrote, elaborate on why you think it was wrong, perhaps justify your own qualitative comparative beliefs (how "better"). 
> 
> As it stands, Webkit's implementation of input type="date" just creates more problems. It should be removed.

It does not stand this way... I'is causing you and other people problems... for me, and other people such support is better than no support.

So again: if there is actual spec violation (e.g. parsing bug) it should be fixed... but do not remove date type just because there is no gui there
Comment 11 Bronislav Klucka 2011-09-16 10:57:15 PDT
(In reply to comment #9)
> (In reply to comment #7)
> > current spin solution is better than having no support at all.
> 
> How do you figure that? Not only does it look ridiculous, and is completely worthless from a user perspective, 

well... I'm working with that element... my customers (using dd.mm. yyyy date format syntax normally) work with that...

For you it looks ridiculous, for you it's worthless... For me and my users? It is not... 

>but it changes the way the input is drawn such that for a particular size there are fewer visible characters.

I can make such argument about text, url, email, color, number....
Comment 12 Bronislav Klucka 2011-09-16 11:05:34 PDT
(In reply to comment #8)
> You can try to read what I wrote, elaborate on why you think it was wrong, perhaps justify your own qualitative comparative beliefs (how "better"). 
> 
How better? It does support validation, it does support one date format (maybe not native to users, but one and easy [much better than datetime... that is uncanny])

Does up button display 1582-10-15? yes. Is it useful? hardly... would it be better if it would display current date? yes.... should we suggest that to webkit team? yes... is it reason for removal? no... for me it is not
Comment 13 Garrett Smith 2011-09-16 12:45:56 PDT
(In reply to comment #10)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > Webkit does provide informations about validity of inserted value
> > > http://test.bauglir.com/winput.php
> > > 
> > That's nice. But can we stick to the input feature itself and not confuse the argument by coupling `date` type with the `required` attribute? Thanks.
> > 
> I'm dealing with the argument that it would be better to remove date and stay with text type... so yeah... let us stay with date and do not mix text there... can we both do that?

The argument is that type=date, as implemented, is buggy and problematic. I understand that you are are using it. However, it is nonetheless buggy and the bugs affect sites.

> 
> > I linked and cited the spec for all the webkit developers. Again, Webkit has introduced a bug where there was none. Browsers have always handled unrecognized INPUT type attribute as "text". For any new HTML5 INPUT type needed, the author can use a strategy to provide a fallback for lacking native support. 
> > 
> > When native support is buggy, as in Webkit, there problem is much harder to solve.
> > 
> > (And BTW, when I click on the up arrow of your example and I see: "1582-10-15" Really useful.)
> 
> I am not justifying any bug here, if there is parsing bug, lets fix it... no need fore type removal... not having GUI is not a bug... 
> 
I gather bug, you mean spec violation. Sure we can talk specs :-).

The user is allowed to set the value to a non-empty string that is not a valid date string. That violates the spec.

[...]

> So again: if there is actual spec violation (e.g. parsing bug) it should be fixed... but do not remove date type just because there is no gui there

The pertinent spec violation again:
| "User agents must not allow the user to set the value to a non-empty 
| string that is not a valid date string."

I can type "1-2-3" into your example. That violates the requirement that user agents must disallow the user from setting anything other than a valid date string. OF course "1-2-3" is not valid but I just entered it. I can even click "submit" but that input is not submitted. Thus the spec violation causes further harm because to the user, it looks like he submitted a date however instead he submitted nothing.

If Webkit wants to continue to allow manually entered dates, they must disallow the user from setting invalid formats (currently fails). And in that case, there is a need for UI indication for the user on what is acceptable input and what is failing.

Otherwise, the user must somehow knowing that a spinner input means that they have to type a valid date format, as defined in HTML5. It is unreasonable to expect the user to know that. 

Manually entered dates must disallow invalid formats (Webit fails here). And in that case, there is a need for UI indication for the user on what is acceptable input. 

While there may be some ways in which type=date is useful, (perhaps for you) there are bugs.
Comment 14 Garrett Smith 2011-09-16 17:02:43 PDT
(In reply to comment #12)
> (In reply to comment #8)
> > You can try to read what I wrote, elaborate on why you think it was wrong, perhaps justify your own qualitative comparative beliefs (how "better"). 
> > 
> How better? It does support validation, it does support one date format (maybe not native to users, but one and easy [much better than datetime... that is uncanny])
> 
> Does up button display 1582-10-15? yes. Is it useful? hardly... would it be better if it would display current date? yes.... should we suggest that to webkit team? yes... 

E.g. 
 
 Date of Birth: [__________]

And then the current date displayed when the "UP" arrow is displayed. Old people on mobile devices will definitely like that one.
Comment 15 Bronislav Klucka 2011-09-16 17:16:16 PDT
(In reply to comment #13)
we are going in circles here... The discussion is not about whether there are any bugs (my code actually show those bugs and how to go around them [using visual and programmed ways])... My involvement starts with your cry "The buggy INPUT type=date should be removed until a suitable UI can be implemented."
So for the last time: the missing UI is not reason for removal at all. If there are bugs, they should be fixed.

BTW. the fact that webkit implementation violates the spec by allowing user to input invalid data in date field should be a separate bug, because UI and this bug are not related
Comment 16 Bronislav Klucka 2011-09-16 17:26:11 PDT
(In reply to comment #14)
> > Does up button display 1582-10-15? yes. Is it useful? hardly... would it be better if it would display current date? yes.... should we suggest that to webkit team? yes... 
> 
> E.g. 
> 
>  Date of Birth: [__________]
> 
> And then the current date displayed when the "UP" arrow is displayed. Old people on mobile devices will definitely like that one.

this is becoming like petty poking to me just for having opinion... Or are you deliberately playing stupid? What ever date you choose as default there are scenarios in which such date would be quite far regardless of input technique... I'm sure, that old people on mobile device would love solution with UI only... scrolling years, months, picking right day on tiny screen calendar without the ability of direct access to input field... on TV screen maybe... I hope this input WILL have ability to direct input regardless of whether it will have calendar-like UI or not...
Comment 17 Garrett Smith 2011-09-16 17:32:27 PDT
(In reply to comment #15)
> (In reply to comment #13)
> we are going in circles here... The discussion is not about whether there are any bugs (my code actually show those bugs and how to go around them [using visual and programmed ways])... My involvement starts with your cry "The buggy INPUT type=date should be removed until a suitable UI can be implemented."
> So for the last time: the missing UI is not reason for removal at all. If there are bugs, they should be fixed.

Yes, for the last time, you still don't get it. 

WebKit UI for that feature being what it is, causes problems. Those problems can be avoided by removing the feature. Simple as that. 

> 
> BTW. the fact that webkit implementation violates the spec by allowing user to input invalid data in date field should be a separate bug, because UI and this bug are not related

Possibly. But this bug report here was to "Add UIs for date..." and so what happened in this bug report is that there was a solution that made it it to production, far from conformant and with insufficient testing (and that is putting it mildly). And so for this bug report, what happened should be undone. 

Don't ship buggy, untested features in the first place and you won't me complain about it.
Comment 18 Garrett Smith 2011-09-16 17:46:03 PDT
(In reply to comment #16)
> (In reply to comment #14)
> > > Does up button display 1582-10-15? yes. Is it useful? hardly... would it be better if it would display current date? yes.... should we suggest that to webkit team? yes... 
> > 
> > E.g. 
> > 
> >  Date of Birth: [__________]
> > 
> > And then the current date displayed when the "UP" arrow is displayed. Old people on mobile devices will definitely like that one.
> 
> this is becoming like petty poking to me just for having opinion... Or are you deliberately playing stupid? What ever date you choose as default there are scenarios in which such date would be quite far regardless of input technique... 

Yet you favor the spinner. Try pushing up arrow. 1582. So awesome I can't comprehend.

I'm sure, that old people on mobile device would love solution with UI only... scrolling years, months, picking right day on tiny screen calendar without the ability of direct access to input field... on TV screen maybe... I hope this input WILL have ability to direct input regardless of whether it will have calendar-like UI or not...

Yes, we get it -- you like direct input. Hey, I do to, FWIW. In the perfect world everybody would know how to type the required format. Unfortunately that's not reality.
Comment 19 Bronislav Klucka 2011-09-16 17:48:41 PDT
(In reply to comment #17)
> 
> Yes, for the last time, you still don't get it. 
> 
> WebKit UI for that feature being what it is, causes problems. Those problems can be avoided by removing the feature. Simple as that. 
Well I get it... Removing would be simple solution.. you are right... I'd rather have the bug fixed


> 
> > 
> > BTW. the fact that webkit implementation violates the spec by allowing user to input invalid data in date field should be a separate bug, because UI and this bug are not related
> 
> Possibly. But this bug report here was to "Add UIs for date..." and so what happened in this bug report is that there was a solution that made it it to production, far from conformant and with insufficient testing (and that is putting it mildly). And so for this bug report, what happened should be undone. 
> 
dtto

> Don't ship buggy, untested features in the first place and you won't me complain about it.

Well nothing against complaint... suggested solution is the problem...
Comment 20 Bronislav Klucka 2011-09-16 17:58:15 PDT
(In reply to comment #18)
> Yet you favor the spinner... Try pushing up arrow. 1582. So awesome I can't comprehend. Yes, we get it -- you like direct input. Hey, I do to, FWIW. In the perfect world everybody would know how to type the required format. Unfortunately that's not reality.

how did you get that? I do not like spin solution... calendar is like one of 4 things I'm missing in webkit now (calendar, datalist, css grids and saving files to actual filesystem from JS and I'll be happy for some time). I do not use spins almost at all (maybe for like 10 days span).. but the spins are not related to whether direct input is possible or not. 

And direct innput vs. calendar? Both would be great... It's cool to use calendar for dates in some range around the current date... but it's much faster to simple type the date of my birthday than to use calendar... and I'm not old...
Comment 21 Bronislav Klucka 2011-10-11 23:47:34 PDT
hello
I'm using 16.0.904.0 dev-m, is that correct that spins have been removed?
Comment 22 Kent Tamura 2011-10-11 23:54:26 PDT
(In reply to comment #21)
> hello
> I'm using 16.0.904.0 dev-m, is that correct that spins have been removed?

Yes, the following types were disabled in Chrome recently to prepare implementing rich UIs.
  date, datetime, datetime-local, month, time, week
Comment 23 Bronislav Klucka 2011-10-11 23:59:33 PDT
(In reply to comment #22)
> (In reply to comment #21)
> > hello
> > I'm using 16.0.904.0 dev-m, is that correct that spins have been removed?
> 
> Yes, the following types were disabled in Chrome recently to prepare implementing rich UIs.
>   date, datetime, datetime-local, month, time, week

ok, U was just about to report to crbug that valueAsDate does not work, but I assume that's related and not bug (since those fields do not have actual date type).
May I ask about the time frame, when those types will be functioning again? My project is not working now...
Comment 24 Dominic Cooney 2012-06-12 20:42:18 PDT
FYI fast/forms/datetimelocal/input-valueasdate-datetimelocal.html is passing on Chromium WebKit waterfall so I updated expectations in r120155.
Comment 25 Kent Tamura 2012-06-12 20:44:33 PDT
(In reply to comment #24)
> FYI fast/forms/datetimelocal/input-valueasdate-datetimelocal.html is passing on Chromium WebKit waterfall so I updated expectations in r120155.

datetimelocal is not enabled in Chromium port. So you don't need to take care of it.
   fast/forms/datetimelocal = TEXT PASS
is enough.
Comment 26 m.kurz+webkitbugs 2017-01-09 01:34:57 PST
Is there a chance we'll see this in Safari on macOS soon?
Comment 27 m.kurz+webkitbugs 2018-08-29 01:32:39 PDT
I think this needs to be re-opened since currently there is no UI for date and time input types (anymore) (Safari on macOS).
Comment 28 Martin Häcker 2019-01-29 01:04:26 PST
+1 for reopening.
Comment 29 Matt 2019-06-28 10:11:03 PDT
+1 For reopening
Comment 30 Sarah 2019-06-28 10:20:09 PDT
+ 1 for reopening
Comment 31 Tim Horton 2019-06-28 11:01:58 PDT
No, let's not reopen this. A new bug would be better; this was for Chromium back in the day.
Comment 32 gnat 2019-06-28 11:30:18 PDT
+ 1 for reopening
Comment 33 Tim Horton 2019-06-28 11:48:28 PDT
Every "+1 for reopening" on this bug delays <input type=date> by one year :)

Please go speak in https://bugs.webkit.org/show_bug.cgi?id=119175 instead if you want.
Comment 34 m.kurz+webkitbugs 2020-10-23 11:40:29 PDT
Starting with Safari TP 115, released on Oct 22, 2020, UIs for `date`, `datetime-local` and `time` are supported on macOS and iOS. The month input type is unsupported on macOS, but works on iOS. The week input type is unsupported on macOS and iOS.
There will be an entry in https://webkit.org/status/ soon: https://bugs.webkit.org/attachment.cgi?id=412182&action=diff

Also see Bug 214946 (duplicate?)