446510 - Implement date/time input types on Mobile

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, enhancement)

Description

[Joshua Cranmer [:jcranmer]]

Considering that we already have an XUL <datepicker>, <input type="date"> should not be too hard to implement.

As a web developer, it's a wonderful thing to not have to re-implement over and over again.

Theoretically, adding
> input[type="date"] {
>   -moz-binding: url('chrome://global/content/bindings/datetimepicker.xml#datepicker-grid');
> }
to a stylesheet should be sufficient, but there is something about XBL that prevents that, I'm told.

Requesting 1.9.1 as it's a useful, easy-to-implement feature.

Comment 1

[Boris Zbarsky [:bzbarsky]]

That wouldn't be sufficient to implement it securely and per spec.

Put another way, that might be fine for a website, but isn't acceptable as a UA impl.

I doubt this is as easy as you seem to think it is.

Comment 2

[Joshua Cranmer [:jcranmer]]

I'll admit I've never done more than dabble in layout code, but the fact that a similar element already exists means that the difficult is certainly less than what it would be if datepicker didn't exist at all.

I'll also admit that I don't know what effect bindings have on DOM, security, or parsing, but, at the very least, it's a start.

Comment 4

[Adam Malcontenti-Wilson]

If implemented, there needs to be some way of a script being able to detect if a datepicker is actually used and interpreted correctly so it can fall back to older javascript implementations.

Comment 5

[Rob Crowther]

There is already a script test, though it's not exactly obvious:

http://miketaylr.com/code/html5-forms-ui-support.html

Some sort of formsUIEnabled flag would be nice.

Comment 6

[Adam Malcontenti-Wilson]

The script test only checks if validation is present on the input, not if the UA is showing any sort of custom UI. For example, Chrome 8 supports all the elements on those page (except color) to some degree and displays them with an up/down - but the test thinks that it doesn't support it due to validation not being enabled. 

So yes, some sort of flag from the browser is required to prevent a "doubling up" of datepickers.

Comment 8

[KLB]

If a date picker is implemented, one issue that needs to be addressed is the date format inserted into the input field.  For instance, a Euro centric website might use 2012-04-23, where as an Americas centric website might need 04/23/2012.  From a usability standpoint,when it comes to the input field, it doesn't matter what ISO standard date format is, what matters is the culturally expected date format.

Opera in their infinite wisdom, has decided to force the use of the 'yyyy-mm-dd' date format for the date input type. Here in the U.S. users will find this confusing and it will make the date input type dead on arrival as we won't be able to use it because it will confuse users.

I don't know what the solution is to this issue, but it does seem that there needs to be some sort of attribute or flag that websites can use to specify the date format to be used on their date input types.

Comment 9

[Robert Kaiser]

(In reply to KLB from comment #8)
> If a date picker is implemented, one issue that needs to be addressed is the
> date format inserted into the input field. 

What date is being *inserted* is not really a question, AFAIK HTML5 defines ISO format, i.e. YYY-MM-DD to be used unconditionally. What is *shown* to the user could be a different question, though, potentially, and could be determined by local (OS/browser) settings.

Comment 10

[Jeff Walden [:Waldo]]

(In reply to KLB from comment #8)
> For instance, a Euro centric website might use 2012-04-23, where as an
> Americas centric website might need 04/23/2012.

Wouldn't the best option be the user's preferred choice?  If I'm most used to reading mm/dd/yy, that would seem the best display choice, regardless of the site's locality.  Indeed, a site that preferred dd/mm/yy, say, could be actively confusing on the point.

By analogy, suppose I'm purchasing something at an overseas site.  Wouldn't it be preferable to see prices in terms of my own currency, rather than a foreign currency, since that's the number that actually matters to me when it comes to brass tacks?

> Opera in their infinite wisdom, has decided to force the use of the
> 'yyyy-mm-dd' date format for the date input type. Here in the U.S. users
> will find this confusing and it will make the date input type dead on
> arrival as we won't be able to use it because it will confuse users.

It may well be confusing to some users, but I don't think it will confuse that many.  Four digits pretty clearly indicates a year.  And while there's ambiguity over which two-digit number is month and which day, in this case that ambiguity is consistent with typical American ordering.

But of course that ordering isn't the same for every locale, so there may be an issue here -- just not for the US.  (I'm not aware of any locales that use yyyy-dd-mm dates, but I'd assume there's at least one.)  The right way to resolve this, it seems to me, is to do it the same way we display any other date.  We can use the OS preferences if those exist (we already do this for displaying dates in Thunderbird, so the code's definitely there).  Or, if the OS doesn't provide this, we can leave it to localizers to choose a reasonable display format.  Or, at worst, we offer a hidden preference (although given that either of the former two options provides a reasonable default, I'm disinclined to impose that maintenance burden for such minor benefit).

Comment 11

[KLB]

If a date picker is used and the date was displayed as the user was used to (e.g. OS preference), I suppose it wouldn't matter too much what format was submitted with the form. Provided the vast majority of browsers in use actually had built in date pickers.

The problem we will face for years to come is that we will have to support browsers that don't have date pickers and try not to confuse users who have to manually enter dates with an "unusual" date format.

Comment 12

[Jeff Walden [:Waldo]]

I'd imagine we can ensure there's some scriptable way to detect support for functional <input type="date"> that includes UI, and then such sites can implement their own datepickers as fallback.

Comment 13

[Robert Kaiser]

(In reply to Jeff Walden (:Waldo) (remove +bmo to email) from comment #10)
> We can use the OS preferences if those exist (we already do
> this for displaying dates in Thunderbird, so the code's definitely there). 
> Or, if the OS doesn't provide this, we can leave it to localizers to choose
> a reasonable display format.

As a long-term localizer, I'd prefer it the other way round: Use a localizable choice and fall back to the OS default if that's not possible. The application can be in a different language than the OS, and having e.g. German formatted dates in an English application (because I run an en-US OS) or the other way round is pretty strange to people, usually. Anyhow, that's a detail. I'd be happy if we'd finally supported HTML5 date input fields at all. ;-)

Comment 14

[KLB]

Another important feature of any date picker is the ability to clear the date field. Currently, Opera's implementation of this does not allow a date to be cleared out after it is entered, which is really unhelpful.

Comment 15

[SK Matic]

As a web developer, the important part of this is how the date is formatted when submitted. YYYY-MM-DD is standard in MySQL and often used in PHP scripts. While the format the date is submitted in should be standard across the board, I agree the date should be displayed to the user in their locale's standard format by default. The question then comes up about JavaScript and it's interaction with the data input element. What format should it be dealing in, or would you be able to set the input's date via JavaScript's Date object?

Comment 16

[Jeff Walden [:Waldo]]

The date format in the form submission is defined by the spec, so there's no discretion for implementations on the point, and no need to discuss that here.  If web developers want some particular format (but really, once there's a format interpreted the same by everyone, who cares?), they should take it to whatwg or one of the W3C lists.

Comment 17

[Rob Crowther]

There is valueAsDate property specified on the date input, it returns a Date object:

http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#dom-input-valueasdate

Comment 18

[Robert Kaiser]

(In reply to Jeff Walden [:Waldo] (busy, try to prefer other reviewers if possible) from comment #16)
> The date format in the form submission is defined by the spec, so there's no
> discretion for implementations on the point, and no need to discuss that
> here.

Right. http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#date-state-type-date and other parts of the spec referenced from there define the on-the-wire format as ISO. Even the conversions to JS are defined in the spec, so the machine-readable side is pretty clear. The presentation is where there's some free room, I think, esp. considering local formats, but I think having an implementation at all is better than trying to be perfect in every regard - esp. considering that B2G will want those controls to be available as well.

BTW, the Lightning calendar project probably has a XUL datepicker implemented, whoever's working on this implementation might want to take a look there as well.

Comment 19

[bastien0705]

Any progress on this? Asking the user to enter a date is a real pain, so I think these are the most useful input types to implement.

As for the format problem, the spec seems pretty clear now: http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#input-impl-notes

Thank you for your wonderful work.

Comment 20

[Florian Bender]

As per Bug 773205 Comment 2 the description of this bug should be changed to something like "implement UI for <input […]"

Comment 21

[hetao]

html5 forms是很重要的功能，为什么不支持color,datetime类型的表单输入呢

Comment 22

[Mounir Lamouri (:mounir)]

If you are interested in the Desktop implementation of those input types, see bug 825294.

Comment 23

[Daniel Trebbien]

I just tested Firefox 27.0 for Android on a Nexus 7 (2013) tablet, and it appears that there is partial support now. Can anyone confirm this? Just curious when this was added and to what extent Firefox for Android implements the HTML5 spec regarding date/time/datetime-local inputs?

I tested the following URLs:
- http://www.wufoo.com/html5/types/4-date.html
- http://fiddle.jshell.net/xgRG5/show/
  (plain input type=date)
- http://fiddle.jshell.net/xgRG5/1/show/
  (plain input type=time)
- http://fiddle.jshell.net/xgRG5/2/show/
  (plain input type=datetime-local)

Comment 24

[Wesley Johnston (:wesj)]

The dependencies for this bug mark when things went in. Looks like pieces landed between Firefox 18 (system pickers) and 20 (dom support). Support should be fairly good.

Comment 25

[marco]

Please get this done, are web application uses this and we are forced to tell our users to use Chrome. I just hate doing this.

Please implement it!
Thanks

Comment 26

[Wesley Johnston (:wesj)]

This is and has been done for a long time. I'm closing this bug.

Comment 27

[Allan Jardine]

For anyone else who was a little confused about this issue being closed - this bug relates specifically to mobile (it was general when the bug was originally opened, and then modified to be specifically for mobile around comment 21/22), you might want to add yourselves to the CC list for bug 773205 which is the HTML5 input types for desktop.

Comment 28

[marco]

Thanks Allan, I was confused about Wesley's reply. I posted on that ticket then to vote/support it.

Comment 29

[Nick]

It's not fixed. HTML5Test claims Firefox doesn't support input date month week time datetime and datetimelocal.

Comment 30

[Wesley Johnston (:wesj)]

We do support a special picker for those modes. They're probably testing for a DOMInterface that isn't implemented though. If you want to dig and find out, feel free to file specific bugs for those things (they may already be filed and linked against bug 773205).

Comment 31

[Florian Bender]

There is no way for client code to check for the "hack" used in Fennec/B2G. This needs the interfaces linked in Bug 888320.