Date/Time Inputs Enabled on Firefox Nightly

https://blog.nightly.mozilla.org/2017/06/12/datetime-inputs-enabled-on-nightly/

by abhinickz • 9 years ago

265 201 9 years ago

blog.nightly.mozilla.org

abritinthebay3• 9 years ago

I know “finally” is a tech cliche but it feels like this has been a REALLY long time coming.

Very thankful we’re starting to see this work roll out!

lucideer3• 9 years ago

First released in Opera 10 in 2009, it seems odd that this feature would take 8 years to develop, considering the proliferate JS+DOM implementations in the wild. I wonder what kept it.

abritinthebay3• 9 years ago

Priorities I guess...

bzbarsky2• 9 years ago

This feature requires that it be a priority at the same time both for the browser UI team and the browser engine team, because of the tight coupling involved to do this right.

There was no point in time before now when this was the case...

saagarjha• 9 years ago

TIL you can render HTML from your address bar:

data:text/html, [Your HTML here]

lucideer3• 9 years ago

You can also render any format, including binaries, by base64 encoding the file contents.

data:text/html;base64,[Your base64 encoded HTML here]

data:image/png;base64,[Your image data here]

The latter is extremely common for embedding static resources directly into HTML pages. To the point there JS APIs the form obj.toDataURL()[0]

[0] https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasE...

oneeyedpigeon3• 9 years ago

The latter is extremely common for embedding static resources directly into HTML pages.

What's the benefit of this? I get that it reduces the number of HTTP requests, but it also fails to cache the resources, so you're betting on the client never requesting that image again (and the client may be a proxy server, right?). It also makes a right mess of your markup, if that's something you care about.

dingo_bat• 9 years ago

Note that there is no picker for <input type=time>. We decided not to support it since we think it’s easier and faster to enter a time using the keyboard than selecting it from a picker.

I wasted about 2 minutes trying to figure out how to input seconds in the embedded example. Turns out it was am/pm. Maybe the picker can be a simple drop-down list.

gvx• 9 years ago

I'm on Fx 56.0.1, but I already enabled the date/time functionality in about:config (key: dom.forms.datetime).

I think you can enable the time picker by toggling dom.forms.datetime.timepicker on. It's on for me, but it isn't the default.

baxtr• 9 years ago

Can somebody explain why this is big news? It looks like a standard input to me. I'm genuinely asking...

wruza2• 9 years ago

Adding date picker to platform after it lived through the peak of world-wide application development is big news itself.

MatekCopatek• 9 years ago

It used to be just a regular text input, from now on it should have a datepicker. Just like all other latest versions of major browsers apart from (desktop) Safari.

yvoschaap• 9 years ago

I think the idea behind a native datepicker for <input> fields is good. But the fact I can't customize the design and UX of the datepicker interface, it always ends up being replaced by some javascript library where I can.

Same goes for the <select> input. The native one is usually always replaced by a custom designed one.

oliv__2• 9 years ago

Agreed. You should really be able to fully style those inputs with bare CSS. Would make life so much easier!

majewsky3• 9 years ago

Okay, please write a proposal for how to select parts of this widget with CSS. Remember, it must be compatible with all major browsers and across all formfactors (mobile, desktop, 10-inch, automotive, etc.). I'll schedule an appointment for a review in 2020, since I don't expect you to be finished earlier than that.

yorwba• 9 years ago

Why do you need to be able to control the look of the date picker (or any other input element)?

If every website used the same, it would be much more convenient than the current situation, where each date picker uses a subtly different mechanism to select the individual fields and then confirm the selected date. Most do not even support keyboard input.

nkristoffersen2• 9 years ago

The best reason for using native form fields (in my experience) is for the mobile devices. Using some old school Jquery custom JS select input means its a very poor experience for mobile. At least on iOS by using native, I get the Safari mobile dates/select inputs that work much better+smoother than js/css alternatives. Of course this doesn't matter if you don't target mobile with your website/webapp.

pault2• 9 years ago

It’s possible to have both; just make your js component issue a synthetic click on a hidden native input, and read the value when changed. I do this all the time.

oliv__2• 9 years ago

OMG this feels like it should have been here AGES ago! Would have saved a lot of pain and jquery-plugin problems...

Great to see it here! I hope it spreads to other browsers quickly.

kkarp• 9 years ago

I hope it spreads to other browsers quickly.

It is in other browsers for years

reustle• 9 years ago

Except Safari iirc :(

Yaggo4• 9 years ago

Nice, but why <input type="date"> expects U.S. format 'mm/dd/yyyy' instead of native format used in my system?

If it falls back to default format, at least the default could little bit more universal/stanard, e.g. 'yyyy-mm-dd'.

Edit: Even after switching my preferred language from English to Finnish in browser settings, the format stays 'mm/dd/yyyy'. I'm using Finnish region in my OS settings as well.

foepys• 9 years ago

In the German localization it's correctly displayed as 'dd.mm.yyyy'. Other formats are possible but not yet enabled for every language, it seems.

Yaggo4• 9 years ago

Weird, given that ´new Intl.DateTimeFormat('fi-FI').format(new Date)´ in console properly outputs dd.mm.yyyy, so the locale data for Finnish should be there.

fnord1235• 9 years ago

Many english speakers use en_US by default since it's the thing that breaks the least, so using the native format of the system is not useful. It should use ISO-8601 (yyyy-mm-dd) unless someone explicitly sets it in about:preferences.

Yaggo4• 9 years ago

Many english speakers use en_US by default since it's the thing that breaks the least, so using the native format of the system is not useful.

Sorry, I'm not following you. Every application should use the format defined in OS settings, that's the point of the system setting, why should browser be an exception?

babuskov• 9 years ago

Agreed. ISO-8601 is the way to go.

madisfun• 9 years ago

That's the reason to use en_GB locale instead. European date and time formats and English language for the UI. Rarely if ever saw anything broken.

_Codemonkeyism• 9 years ago

Didn't you know? There does not exist a world outside the US. We're all just illusions and bots.

Manishearth5• 9 years ago

It uses the locale of your Firefox install (which you can select when you download the browser). This isn't configurable within an install (yet).

petriw• 9 years ago

I hope the plan is to read the configured date format on the system like most software out there? This really shouldn't need to be manually configured.

jhasse6• 9 years ago

Works on Android though (or does the Play Stpre download a localized version for me?).

mozumder• 9 years ago

This is a nice start but we basically need a full API of these to match all the widgets and view controllers you find in a full GUI environment like Mac OS/Windows/iOS.

wruza2• 9 years ago

People who don’t give a fcuk about controllers and patterns outnumber traditional folks heavily, so there is no place to look for understanding of it today. Just wait and someday you’ll hear about Element Group Management or whatever classic weathered MVC would be called then. Don’t miss that year though, check regularily.

snitko• 9 years ago

It looks like the date is displayed in the US format mm/dd/yyyy which is, of course, most unnatural to all other countries. Is this customizeable, or is it automatically adjusted depending on the language preferences in the browser? If it's the latter, it's not cool - my preferred language for the browser is English, but I hate the US date display format with passion.

EDIT: oh I see, automatically adjusted, but not configurable. Bad choice it is, then.

EDIT2: I mean, there are so many more better and easy solutions to that problem. You could display a date with a month name in the selected language - "Oct 1, 2017" - or start with a year "2017-10-01" which would be instantly recognizable by anyone regardless of the country.

Aeolun• 9 years ago

Only in the sense that people won't be taught to use sane date formats. I don't see any issue with allowing someone who wishes to use the weird format to have their way.

Edit: If you downvote it, be nice enough to let me know what you disagree with.

Majestic1212• 9 years ago

The downvotes are probably because you seem to miss the point of the parent.

The issue is not about the possibility to have a weird format, the issue is that the format is automatically adjusted to the "weird" one that a lot of people don't like, and that it is not easily configurable.

Yaggo4• 9 years ago

At least on macOS it seems not to be automatically adjusted. It still displays me the illogical mm/dd/yyyy format, despite my Firefox having 'Finnish' on top in language settings.

Ideally the application should read the system regional setting and use that. For example, my macOS uses English as language and Finnish as region. (I've no idea if the system provides an API for reading regional settings, though.)

metafunctor2• 9 years ago

Confirmed.

The MacOS system, of course, provides APIs to get language and locale settings (for dates, number formatting, etc.) separately.

The JavaScript environment, on the other hand, doesn't really have any good APIs that properly separate preferred language from other things like units (metric vs. imperial), formatting dates and times, currencies, and so on.

I was hoping this would be an improvement to the state of JavaScript wrt. locales. Sadly, it looks like this build of Firefox Nightly still doesn't do dates correctly on MacOS, and this is just as broken as everything that came before it.

I have language, dates, number formatting, and everything set up just the way I like it in the OS settings, why the web/JS world just doesn't use those settings is beyond me.

maggit4• 9 years ago

That's an awful shame. I can't really see myself using this when authoring websites as long as it has that behaviour. If I am authoring a Norwegian web site, the date format must be Norwegian, regardless of the user's preferred locale.

alkonaut3• 9 years ago

I can see how customizable locale/formatting would be important, but would it really matter if a US visitor to the Norwegian website saw a mm/dd/yyyy date instead of the yyyy-mm-dd that would be shown to those with norwegian locale? The important thing seems to be that the user understands the format. This is client side rendering after all.

nkristoffersen2• 9 years ago

I build interfaces for Norwegian web applications pretty often. Why must the date format be Norwegian? Obviously this is just the form field, you shouldn't actually store the data as displayed. I typically store UTC/ISO strings for all dates, but in this case I would store it in whatever format I needed (such as the Norwegian format), regardless of what the format was on the form. Never trust client-side, right?

kyberias3• 9 years ago

That doesn't make much sense. Why would you override USER'S PREFERRED LOCALE just because your website language is something else?

ptero2• 9 years ago

If I am authoring a Norwegian web site, the date format must be Norwegian, regardless of the user's preferred locale.

If I understand you correctly, this is something I strongly disagree with. Many people are bilingual if not more, so when I have two tabs from different sites I prefer the dates to be consistent. At least on my Linux machine I want those to be driven by my locale settings, which lets me choose UK English, US English or 50 other conventions if I so desire.

I routinely run terminals with different locales set on the same screen and I would like programs started from those not get smart about locale choices but rather do exactly as I ask. Just my poor user 2c.

iamphilrae• 9 years ago

This would be terrible for usability. Allow the user to see the date how they want, then you process the data that’s returned.

robin_reala3• 9 years ago

Grab the en-GB Firefox release? You get dd/mm/yyyy then.

https://www.mozilla.org/en-GB/firefox/all/#en-GB

jochung2• 9 years ago

Why is this read off the firefox locale when my system has perfectly decent localization capabilities set up just the way I like it? (US English, 24h, YMD) This seems like another case of the browser becoming an OS within an OS.

fnord1235• 9 years ago

I have "intl.accept_languages" set to "en-GB,en". "general.useragent.local" is "en-GB". My system preferences are UK English. Yet this new firefox feature gives me the US date format.

mrmondo• 9 years ago

Yeah I thought that was really confusing! I would have expected that for countries that commonly read left to right and count from small to big the format of day(smallest common date unit)/month/year(largest common date unit) would at least be a sensible default if unable to detect the exact clients country standard, failing that the ISO of YEAR-MONTH-DAY would be fine but not jumbling it up like this and putting the day between the month and year - I know my comment could sound a bit ‘flamey’ but I’m purely interested / invested from the point of view of logical or biology, I don’t care about ‘X country does Y better’.

afafa12• 9 years ago

That would be the case if not the fact US used date format different to everybody else. Is 01/05/2000 1st of May or 5th of January? The answer is: cannot tell without context!

vog• 9 years ago

Note that the format "2017-10-31" is also an ISO standard (ISO 8601), so when in doubt, this is the most sane default you can have.

Crontab• 9 years ago

Agreed. I personally use it everywhere I can because it makes it easy to sort anything that is date/time based.

_0w8t• 9 years ago

From my experience people outside IT or science may not have recognize ISO format as a date. Using US ordering with a word for the month in the native language can be safer default.

Manishearth5• 9 years ago

You have to download the en-GB localized browser to get a different date ordering.

Firefox serves localized downloads by default, and you can also manually get the right one (IIRC it lets you override it on the download page)

vim_wannabe• 9 years ago

I'm confused, if the operating system is set to use some date format why not use that? You don't need to even reveal the format to Javascript since the input should work without JS.

Language preferences are a totally separate thing, although they could be used as a fallback if date format is somehow not offered by the operating system. E.g. de-CH for a swiss date format, de for a german date format.

b212• 9 years ago

I'm wondering how difficult (if not impossible?) it would be to change the format in the US.

It makes no sense whatsoever and the US seem to be the only place in the world to use mm/dd/yyyy excluding a few countries in Africa (and even there it's not the most popular format):

https://i.guim.co.uk/img/static/sys-images/Guardian/Pix/pict...

https://en.wikipedia.org/wiki/Date_format_by_country

tankenmate• 9 years ago

Welcome to the world of middle endian.

And for this reason the ISO standard is yyyy-mm-dd, big endian just like writing numbers; and it sorts (numerically not lexigraphically) properly too!

yjftsjthsd-h• 9 years ago

I would expect that to be exactly as difficult as converting from Imperial to metric units in general, which has been a complete and utter disaster so far.

hungerstrike4• 9 years ago

It makes sense because of the way that you say it. “January 1, 1970” == 1/1/1970.

Other formats don’t make sense.

baby• 9 years ago

Why don't they use the ISO standard for displaying dates? month-day-year makes no freaking sense.

Plus there are no way to distinguish month-day to day-month in a lot of cases

BLanen• 9 years ago

Because you didn't actually read the article.

codeulike• 9 years ago

Um ... Displaying dates based on locale of client has been the standard for most software for decades. Why call out Firefox for this, now?

rypskar• 9 years ago

Because this is not displaying dates based on the locale of the client, but displaying locale based on the language of the application.

cfstras• 9 years ago

Obligatory XKCD: https://xkcd.com/1179/

I agree, though. Browsers allow users to customize fonts and zoom levels, so the date formats should probably be a user-configurable setting, too.

BrandoElFollito3• 9 years ago

The last one is actually the ISO norm. There was of course an xkcd on that subject as well.

claudius• 9 years ago

Hopefully it will stop people implementing their own date/time pickers which only allow changing that date/time by clicking up/down arrows. In particular the Munich transport website (mvg.de) is guilty of this and I absolutely hate it with a passion.

majewsky3• 9 years ago

Of course it won't. Public service providers in particular need to provide compatibility down to the likes of IE 7.

yosamino3• 9 years ago

To be fair, there would be a relatively easy way to test for support to implement a fallback.

  var el = document.createElement("input");
  el.type = "time";
  var supported = (el.type == "time");

If only there wasn't a bug on firefox mobile that would return "text" even if the input field type is supported.

... mhmmm webdevelopment...

ptman• 9 years ago

finally not only in chrome (and apparently opera)

mullsork• 9 years ago

Chrome has had this for what feels like years. Is there something new in there or did Firefox just catch up?

Good news in any case! The back office tool I work on is Chrome only and it's been great to just use type="date"!

gkya• 9 years ago

I guess most of us saw it for the first time used in the url bar. It did surprise me too altho I knew how they were used to embed images and such.

Zash• 9 years ago

But what format is the data sent to the server in?

MattBearman• 9 years ago

ISO 8601 (yyyy-mm-dd)

moogly3• 9 years ago

No timezone part? Or UTC (w/ Z)?

bzbarsky2• 9 years ago

For <input type="date">, it's a https://html.spec.whatwg.org/multipage/common-microsyntaxes.... (see <https://html.spec.whatwg.org/multipage/input.html#date-state... though you have to know how the inputs section of the spec works in general to see that it enforces the "valid date string" constraint). To translate from spec to something readable, it's YYYY-MM-DD, with nothing else.

For <input type="time"> it's <https://html.spec.whatwg.org/multipage/common-microsyntaxes..... Again, to translate to something readable, it's HH:MM[:SS] where the :SS part is optional if seconds is 0, and all numbers are 0-based (so 0 <= HH <= 23, 0 <= MM,SS <= 59).

For <input type="datetime-local"> it's https://html.spec.whatwg.org/multipage/common-microsyntaxes.... which is yyyy-mm-ddThh:mm[:ss] without any timezone information, afaict, and with [:ss] guaranteed to be left out if 0.

ComodoHacker• 9 years ago

Side note: I was trying to think up a viable case for applying @step attribute to date input but quickly gave up.

brucen2• 9 years ago

If something runs weekly (e.g., every Saturday), it could be useful to verify the user has picked a Saturday. Not sure if the dropdown would grey out other days too, as that could be useful to be able to remove unavailable days.

mattmanser5• 9 years ago

You generally want the converse, the ability to block off Saturdays and Sundays.

pette• 9 years ago

This is not newsworthy.

But will the inputs be mixed-reality ready?

amelius4• 9 years ago

Nice, but their design doesn't match my website's design.

miguelrochefort4• 9 years ago

This right here is one of software's biggest problem.

Businesses have the hubris of designing their own custom UIs for everything, deeply tainted with their branding, and they all end up reinventing the wheel because standard solutions aren't compatible with their designs.

It's time to dissociate software from branding, so we can free 90% of developers and have them do something useful for once.

amelius4• 9 years ago

It's time to dissociate software from branding, so we can free 90% of developers and have them do something useful for once.

And how should we do that? Isn't that what CSS tried to do (but failed)?

Perhaps we should invent a different title for programmers that do relatively simple work, like writing CSS and perhaps some easy javascript. That way, the real programmers can more easily say "that's not in my job description".

Brosper• 9 years ago

Finally? God why it to them so long to implement the most basic thing :(

mattmanser5• 9 years ago

Statements like this show how ambiguity creeps in:

All dates and times will be converted to ISO 8601 format, as specified in the spec, before being submitted to the web server.

Are you going to be appending a Z? Adding the browser's timezone? Adding T00:00:00Z to the dates? What? No clarity at all. You can't just hand wave and say 8601! 8601!

Also, we've had date and time pickers for over a decade now and this clearly doesn't meet the need.

It's such a shame that this is the standard they come out with.

yosamino3• 9 years ago

First things first: The scope of this control is to let you pick a time, the hour and the minute of a day. Possibly from a native widget (i.e. on mobile it pops up a clock where you have to select an hour and a minute). It is then submitted without a timezone, not +0, just without.

The timezone is simply out of scope for this, and with good reason: Presumably the time a user enters will be interpreted in one of two ways:

* A javascript application running in the users browser, which already knows what the users current timezone is.

* An application running on a server somewhere, which will have the information of "a user submitted a time without a timezone", which is valuable information and very often that is exactly the correct way to interpret a time.

In the case very it's absolutely necessary to know the exact timezone a user wants to specify, it's very easy to add a widget to let a user specify the timezone. But I feel that's something that is much, much less common than letting a user set a simple time, so it makes sense to optimize for that.

mattmanser5• 9 years ago

First things first: I'm talking about the date picker

The time picker has it's own problems, like the Oh, So Useful! seconds part. And that most people use drop-downs for this, but they say entering a time by hand is better (when it's not).

A lot of my client work at the moment is within the entertainment industry where obviously we need to pick times all the time. Both startups I work with use hour dropdown, [00, 15, 30, 45] minute drop down. One uses 24 h, one uses an AM/PM dropdown. You don't want people typing 12:07:03.

That time picker is not fit for purpose and I wouldn't be able to use it.

(Also, you don't seem to acknowledge this is a form control and you shouldn't need to use javascript to muck around with it before submitting it).

LukeShu2• 9 years ago

No clarity at all. You can't just hand wave and say 8601! 8601!

No, but you can hand wave and say "as specified in the [HTML5] spec", with a link to the spec, and have the spec cover the details.

But really the answer is: ISO 8601 specifies standard formats for both datetimes (what you are referring to), and plain dates (YYYY-MM-DD). When an article says that a date is converted to ISO 8601 format, isn't it obvious that it means ISO 8601 date format, not ISO 8601 datetime format?

(Additionally, the spec doesn't say "8601 format", it specifies the format, and notes that it is "based on" 8601 format).

gldalmaso• 9 years ago

What is the reasoning behind the decision to not make localization configurable?

Can we agree that some webpages and webapps have already make the decision to control the locale through the app and not choose the environment default?

My OS and browser locale is pt-BR, but if for whatever reason I am not happy with a pt-BR UX, which is often, I want to be able to change it on a case by case basis.

For example, any documentation I look up, like say on MDN or AWS, I want to see it in english and not a poor/incomplete translation. If I play a Star Wars game on my browser or phone I do not want any translations, I want the original terms like scoundrel instead of the translator's choice of terms.

It is already bad enough as it is for the reasons I pointed out, now we are gonna have that same nightmare in forms as well?

Sure webapps that actually care will find a non standard way, as they already do, but then we are not actually improving when in 2017 you have to load 3rd party libs just to be able to choose the locale of a date input.

<input type=date> (environment default)

<input type=date locale="pt-BR"> (actual chosen locale)

Is that too much to ask?

jhasse6• 9 years ago

I wouldn't want websites to overwrite my locale setting like that.

jeltz2• 9 years ago

But they already do it for dates in the content of the pages (there is no API for a web server or JS to get the browser UI locale). Why should form elements be different? Imagine how confusing a web site with a D/M/Y dates and a browser with M/D/Y forms would be.

Hussell2• 9 years ago

I want the content, number formats, date formats, map labels, etc. on my website to all use the same locale. Date input widgets are no exception.

I can't afford to give full support to all locales (translation costs are ridiculous), so detecting and supporting the user's locale seems to be pointless unless they happen to be using one of the limited set I can give full support to (en-CA and fr-CA in my case). It seems like a far better idea to allow the user of my website to choose one of the supported locales, and see everything in the same consistent format than to have a few input widgets on each page decide to configure themselves based on the locale the browser was compiled with.

Edit: also, consider testing. Am I supposed to download a bunch of variants of Firefox to test my locale support?

nonsince2• 9 years ago

Ideally there would be a better way to choose locale on a per-site basis rather than having it be baked into each app individually. Many apps have no settings page, and those that do often require you to log in to change the settings.

I have my browser language set to Dutch but every time I touch Wikipedia or MDN I have to append "english" to my search terms to get a version of the article that isn't strictly inferior.

c-smile• 9 years ago

According to HTML5 specification this:

    <input type=date lang="pt-BR">

shall work.

Like here: https://sciter.com/temp/date.png

4827947937928944• 9 years ago

The reasoning is that this is a brand-new feature that just landed in the Alpha release of the browser and they're just not done yet with every secondary implementation aspect.

Manishearth, who's a Mozilla dev, commented in another thread that he's currently looking into making it configurable.

giancarlostoro• 9 years ago

I know everyone's ticked off about the "US defaults" but it's released in a development / testing browser, not the typical Firefox release. They'll likely do adjustments based on feedback. I hope it becomes configurable. Definitely easier than importing some external libraries though.

Given how this was setup in a nightly release they're very likely to start out "a little broken."

Really glad this is finally being added, I'm sure there's other features some of us wouldn't mind in HTML out of the box.

Update: Realized it's released on nightly not "Developer's" edition.

Flimm• 9 years ago

I'm not sure it's true that they'll adjust to feedback. Chrome has already shipped a similar feature, and it has identical problems, IIRC. I think it's quite likely Mozilla will just ship whatever is closest to Chrome's behaviour, regardless of user feedback.

4827947937928944• 9 years ago

Well, Firefox is not Chrome. Firefox usually supports things more completely than Chrome, partially because that's just what they do, they safeguard webstandards, so delivering a standards-compliant browser is a main-goal, but in large parts also because the community will make Mozilla go the extra mile with code contributions, if they don't do it themselves.

And a Mozilla dev, Manishearth, has commented above that he is in fact currently looking into making it configurable.

mdf2• 9 years ago

This is very nice, but the system LC_TIME locale (and whatever the equivalent is on Windows) exists for a reason. I hope Mozilla will listen to the feedback in all these comments and consider basing the picker type on the system time locale – not on the language locale, and certainly not on the locale of the downloaded binary.

I use most if not all software in English, but I prefer seeing dates in the ISO format, weeks starting from Mondays and times in a 24 hour format.

idbehold• 9 years ago

Does having your weeks start on Monday get confusing at all? I guess I'd just find it weird to have Thursday be the middle of the week instead of Wednesday. I also just find dates weird in general since it seems to use 1-based indexing whereas time uses 0-based indexing. First month and day of new year? 01-01. First hour, minute, and second of new day? 00:00:00.

mdf2• 9 years ago

Does having your weeks start on Monday get confusing at all? I guess I'd just find it weird to have Thursday be the middle of the week instead of Wednesday.

Quite on the contrary! Wednesday is still in the middle of the working week, leaving the two day weekend kind of as a special separate thing. :)

ComputerGuru• 9 years ago

We've been using this in a corporate webapp for over two years in a Chrome environment. I can't believe Firefox is only just getting this. You'd think basic form inputs would have a UI this late in the game without needing to pull in something like jQuery UI or similar.

Especially given how hard it is to implement dates and calendars correctly.

ourcat• 9 years ago

I wonder if this had anything to do with Microsoft, Google, Mozilla, etc. recently deciding to consolidate web documentation at MDN. https://blog.mozilla.org/blog/2017/10/18/mozilla-brings-micr...

Since I recently tried to implement a date input and was shocked to discover that Firefox didn't support it, despite being in 'their' docs. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

JCSato• 9 years ago

Ran into similar shock recently while working on a project. Ended up just making my own - was actually fairly straightforward, and pretty fun. Creating 6 <select> menus for date time input would have been obnoxious enough as a developer, but I can't imagine filling that in as a user and not hating the experience. Glad to see Firefox moving in this direction.

_Microft• 9 years ago

Every article (where applicable) should have a browser compatibility section near the end of it. (It's not such a new thing though)

In your case:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

4827947937928944• 9 years ago

Nah, it's been on Mozilla's To-Do list for years already, just realistically not ever really a priority.

And I'm also pretty sure they've already been actively working on the implementation prior to talks with those companies. I think, I remember reading about first design steps at the start of the year already.

greggman• 9 years ago

I'm curious about Japanese support which I think goes beyond locale.

Japanese often uses 24 hour times like 18:00 vs 6:00pm and while I see you can specify valid times in that format I didn't see how to get it to display 18:00 instead of 6:00pm.

In the forms on this page

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

When I typed 20:00 it assumed that first 2 meant 2am and then jumped to the minutes section as soon as I typed 2. Note: My system settings are set to use 24 hour time.

Worse, Japanese times are often in terms of the night before. So for example if you look at movie times a movie playing at 1:00am Saturday morning is listed as 25:00 Friday night.

I wonder if input type=time is probably going to cause more trouble than it's worth

nonsince2• 9 years ago

One problem with internationalisation attempts is that most of the committees that have control over these things are from the Americas or Europe and so speak a Romance language natively and almost certainly speak English well (if not natively). There is nowhere near enough input from languages and cultures that might not fit European norms. There's a great article about a similar problem in Unicode:

https://modelviewculture.com/pieces/i-can-text-you-a-pile-of...

gh02t• 9 years ago

In this particular case though, 24 hour time is common in Europe and even in the US it's somewhat common (I use it). I curious how they could have overlooked it (partially).

Majestic1212• 9 years ago

24h clock is very common in France, and other European countries as well

kawsper• 9 years ago

I am from Denmark, so I am mostly used to dealing with 24 hour clocks, I know it is simple for others but AM/PM gets me so confused, we do not use the 25:00 format as you.

Now I live in the UK, and I still have to convert my friends to be using 24 hour clocks, maybe it will help if I start showing up at their houses at 05:00 instead of 17:00 :D

BrandoElFollito3• 9 years ago

TV hours work the same in France, except that a movie playing at 01:00 on Saturday will be listed on Friday, at 01:00. In other words, the first item listed on a given day is at, say, 9:00 that day despite the fact that other things were played earlier. The TV day then ends at, say, 6:00 the day after.

I am not sure of the hours because I haven't actively watched TV for years but it was certainly the case when I was a kid in the 80's where TV was not 24/24 but ended sometime in the night. It was then natural for the next day to start at 9 or whatever was the earliest broadcast.

finalfantasia• 9 years ago

This feature has already ridden the release train (currently in 57 beta) [1] and should be released with Firefox 57 next month.

[1] https://www.mozilla.org/en-US/firefox/57.0beta/releasenotes/

ape4• 9 years ago

Any ideas on how a website should use this? Can you detect if input.date exists easily (for the current browser) without resorting to checking the brand and version of the browser?

kemayo• 9 years ago

Modernizr detects supported input types: https://github.com/Modernizr/Modernizr/blob/master/feature-d...

It's basically just making an <input>, setting its @type and seeing if that sticks, then setting a known-invalid value and seeing if that sticks.

mixedCase• 9 years ago

No week picker? Edge and Chrome implement it.

ajnin• 9 years ago

One of the date examples shows a box with "06/09/2016" in it, with an error popup which says "Please select a valid value. The two nearest valid values are 2016-06-06 and 2016-06-11".

Seems incoherent to use US date format for the box and ISO8601 format for the error message.

Also I wish software in general would stop trying to guess what the locale settings should be and just ask. I have my language set as en_US but I prefer to use 24h time and ISO8601 dates. With this update Firefox guesses wrongly 12h time and mm/dd/yyyy date format with no way to override it that I could find.

4827947937928944• 9 years ago

Note that there is no picker for <input type=time>. We decided not to support it since we think it’s easier and faster to enter a time using the keyboard than selecting it from a picker.

I've thought this so many times, even on my phone where typing is less accessible, I still prefer it over those analogue clock face inputs.

With such a clock input, I'll often hit the wrong time, either an hour/minute too late/early, due to my apparently fat fingers, or 12 hours wrong, because I live in a 24-hour-format region where normally on an analogue clock you read things in 12-hour-format and so my brain thinks "8 pm" and enters "8" when it should have chosen "20". That doesn't happen with typing, because digital clocks almost always display 24-hour-format.

And even worse, in an attempt to speed things up, someone came up with the ingenious idea of directly advancing from hour input to minute input as soon as some input has been made. So, my first few wrong inputs then mean that I have to find the way to get back to the hour selection multiple times.

Date/Time Inputs Enabled on Firefox Nightly

Related Stories