Bug 29359 – Add UIs for date and time types of <input>

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

[Kent Tamura]

Add dedicated UIs for type=date, datetime, datetime-local, month, time, week.

[Holger Jeromin]

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.

[Holger Jeromin]

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.

[Chris J. Shull]

This would be really nice. Is there a way to nominate?

[Deirdre Saoirse Moen]

<rdar://problem/8948907>

[Kent Tamura]

(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.

[Garrett Smith]

(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.

[Bronislav Klucka]

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.

[Garrett Smith]

(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.

[Chris J. Shull]

(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.

[Bronislav Klucka]

(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

[Bronislav Klucka]

(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....

[Bronislav Klucka]

(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

[Garrett Smith]

(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.

[Garrett Smith]

(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.

[Bronislav Klucka]

(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

[Bronislav Klucka]

(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...

[Garrett Smith]

(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.

[Garrett Smith]

(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.

[Bronislav Klucka]

(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...

[Bronislav Klucka]

(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...

[Bronislav Klucka]

hello
I'm using 16.0.904.0 dev-m, is that correct that spins have been removed?

[Kent Tamura]

(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

[Bronislav Klucka]

(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...

[Dominic Cooney]

FYI fast/forms/datetimelocal/input-valueasdate-datetimelocal.html is passing on Chromium WebKit waterfall so I updated expectations in r120155.

[Kent Tamura]

(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.

Is there a chance we'll see this in Safari on macOS soon?

I think this needs to be re-opened since currently there is no UI for date and time input types (anymore) (Safari on macOS).

[Martin Häcker]

+1 for reopening.

[Matt]

+1 For reopening

[Sarah]

+ 1 for reopening

[Tim Horton]

No, let's not reopen this. A new bug would be better; this was for Chromium back in the day.

[gnat]

+ 1 for reopening

[Tim Horton]

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.

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?)