11 ms·

Date/Time Inputs Enabled on Firefox Nightly

265 points by abhinickz 9y ago

Yaggo 9y 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 9y 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.
  - Yaggo 9y 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.
- fnord123 9y 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.
  - Yaggo 9y 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?
    - DiabloD3 9y ago
      Most people intentionally set their locale wrong, to en_US, because a lot of apps simply do not have actual locale support, but try to do something when presented with a non-en_US locale.
      - NetMonkey 9y ago
        I know many like me, who also just prefers the application language to be in English. From decades of using English I have no idea what many terms are in my native language, native terms are much harder to google, and many applications are also poorly translated. But that doesn't mean I want everything in English, especially not date/time formats.
        viraptor 9y ago
        Language and locale (how you want your date or numbers formatted) are two different things. You can set them separately.
        Piskvorrr 9y ago
        I can set them, all right. Somebody else then needs to read them, though...and has to take care not to assume that LANG===LC_TIME===LC_DATE. Sadly, I do not see that happening; in most cases, the apps are picking one locale setting, seemingly at random, and using it for all the other locale settings.
      - beejiu 9y ago
        I cannot remember an app that did not support dd/mm/yyyy format. It is the first thing a non-US English speaker will complain about.
        fnord123 9y ago
        Last time I used Peoplesoft it had everything in American date format.
        9y ago
  - babuskov 9y ago
    Agreed. ISO-8601 is the way to go.
  - madisfun 9y 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.
    - fnord123 9y ago
      Yes I try to do that but I sometimes have used (accidentally) en_US in the past since I use ANSI International keyboard layout but GB locale settings.
- _Codemonkeyism 9y ago
  Didn't you know? There does not exist a world outside the US. We're all just illusions and bots.
- Manishearth 9y 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 9y 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.
  - jhasse 9y ago
    Works on Android though (or does the Play Stpre download a localized version for me?).
    - Manishearth 9y ago
      IIRC it does
mozumder 9y 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.
- wruza 9y 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 9y 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 9y 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.
  - Majestic121 9y 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.
- Yaggo 9y 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.)
  - metafunctor 9y 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.
abritinthebay 9y 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!
- lucideer 9y 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.
  - abritinthebay 9y ago
    Priorities I guess...
    - user5994461 9y ago
      I'd say localization.
      - scott_karana 9y ago
        Judging by the lack of format customization and Gregorian-only support, I doubt i18n was the delay. ;)
        abritinthebay 9y ago
        To be fair - that covers all areas the ISO date format covers.
  - bzbarsky 9y 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 9y ago
TIL you can render HTML from your address bar: data:text/html, [Your HTML here]
- lucideer 9y 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/HTMLCanvasElement/toDataURL https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasE...
  - oneeyedpigeon 9y 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.
    - Xophmeister 9y ago
      They can be embedded within a resource that is cached (e.g., an HTML page or CSS stylesheet).
      - oneeyedpigeon 9y ago
        True; I guess they're then beneficial if the resource is only ever used on that one page.
      - majewsky 9y ago
        For an example, see the SVG icons embedded in this CSS: https://fsfw-dresden.de/theme/css/fsfw.css https://fsfw-dresden.de/theme/css/fsfw.css (search for ".logo-twitter", for example)
dingo_bat 9y 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 9y 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 9y ago
Can somebody explain why this is big news? It looks like a standard input to me. I'm genuinely asking...
- wruza 9y ago
  Adding date picker to platform after it lived through the peak of world-wide application development is big news itself.
- MatekCopatek 9y 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 9y 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__ 9y ago
  Agreed. You should really be able to fully style those inputs with bare CSS. Would make life so much easier!
  - majewsky 9y 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.
    - amelius 9y ago
      That's why they should have written the controls in Javascript and put it on their CDN, or include it in the browser distribution. Then using the controls would only require a simple include in the head of the document, and you could style the controls just like any other HTML.
      - keganunderwood 9y ago
        No, push back against insane requirements. Why do we want to style input? Bill them for a custom solution if they want a custom solution.
    - dbbk 9y ago
      There are already ways to style native UI widgets, you can even style scrollbars...
oliv__ 9y 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 9y ago
  > I hope it spreads to other browsers quickly. It is in other browsers for years
  - reustle 9y ago
    Except Safari iirc :(
    - robin_reala 9y ago
      Or IE11: http://caniuse.com/#feat=input-datetime http://caniuse.com/#feat=input-datetime
claudius 9y 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.
- majewsky 9y ago
  Of course it won't. Public service providers in particular need to provide compatibility down to the likes of IE 7.
  - yosamino 9y 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 9y ago
finally not only in chrome (and apparently opera)
mullsork 9y 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 9y 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 9y ago
But what format is the data sent to the server in?
- MattBearman 9y ago
  ISO 8601 (yyyy-mm-dd)
  - moogly 9y ago
    No timezone part? Or UTC (w/ Z)?
    - Manishearth 9y ago
      No. It's up to the application to decide how it wishes to interpret timezones. Or if timezone should be a factor at all. E.g. if I'm booking a hotel you don't want it to pick up the user's timezone and frob that into UTC to send it over; you want the local hotel timezone. But if you're setting a calendar event you do want the timezone to be configurable, and you can add a picker for that. Assuming all time fields must have a timezone is why e.g. jekyll will re-date your prior posts (breaking all URL slugs) when you change your timezone.
      - moogly 9y ago
        > if you're setting a calendar event you do want the timezone to be configurable, and you can add a picker for that I suppose. In the product I'm current working, I guess technically we could add a TZ dropdown as you describe, but it'd go unused because the kind of events our users schedule, they want to use their current corporate local time always (there's no travelling across timezones involved for our users), and we need to know what time that is over here, so in lieu of one useful form field (UTC or datetime offset), we'd now have to send two (change the dropdown to a type=hidden), or another one with a "proper" datetime string. I guess not the end of the world[1], but it does introduce more opportunities for bugs. From what I've seen, few products have that timezone dropdown, and usually it tends to be an override that still needs a sensible fallback, and no information as to what timezone the current user is in gives you absolutely nothing. DateTime offset lets the application handle most cases, so that's what I prefer to use. [1]: also needs a timezone
ComodoHacker 9y ago
Side note: I was trying to think up a viable case for applying @step attribute to date input but quickly gave up.
- brucen 9y 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.
  - mattmanser 9y ago
    You generally want the converse, the ability to block off Saturdays and Sundays.
    - brucen 9y ago
      Depends on the application obviously. A lot of social groups would likely be meeting once a week. It's just a simple example though of how the step function could be useful. For your example, you would just need a step with some kind of range. So you could say step=7, range=5 to allow them to pick from the first 5 days of every 7 (or to get trick step=7 range=-2 to eliminate the last 2 days). I'd hazard a guess they thought about this kind of stuff, but realised it would be complicated pretty quickly.
      - mattmanser 9y ago
        Most applications are enterprise apps, the vast majority of apps in the world today are enterprise apps. That work Mon-Fri, so want to restrict date pickers to Mon-Fri. And it doesn't have range, does it? So the infinitely more useful range hasn't been specified, but the almost useless step has. https://html.spec.whatwg.org/multipage/forms.html#forms https://html.spec.whatwg.org/multipage/forms.html#forms
pette 9y ago
This is not newsworthy. But will the inputs be mixed-reality ready?
amelius 9y ago
Nice, but their design doesn't match my website's design.
- miguelrochefort 9y 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.
  - amelius 9y 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".
    - miguelrochefort 9y ago
      I don't want software to be branded at all. I want all apps to look and behave the same, to the point where they're all just one app. Nobody asked for their shopping experience to be different when shopping on Amazon vs eBay vs Craigslist. I see no compelling reason to have different UI for services that are essentially identical.
      - felipeko 9y ago
        So, who gets to decide what it all look like? The broswer vendor? W3C? What if one browser does something others won't, and you can't do it custom, how do you get around it? Wouldn't that put us back to IE6 web? What if your site really needs something browsers don't have? Will we have sites telling us to install a plugin and put us back to Flash era?
Brosper 9y ago
Finally? God why it to them so long to implement the most basic thing :(
mattmanser 9y 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.
- yosamino 9y 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.
  - mattmanser 9y 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).
gldalmaso 9y 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?
- jhasse 9y ago
  I wouldn't want websites to overwrite my locale setting like that.
  - jeltz 9y 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.
    - jhasse 9y ago
      > (there is no API for a web server or JS to get the browser UI locale) There is: new Date().toLocaleDateString()
  - Hussell 9y 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?
deleted 9y ago
[deleted]
giancarlostoro 9y 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 9y 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.
  - 482794793792894 9y 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.
mdf 9y 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 9y 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.
  - mdf 9y 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 9y 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 9y 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-microsoft-google-w3c-samsung-together-create-cross-browser-documentation-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/input/date https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
- JCSato 9y 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 9y 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/input/date#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
- 482794793792894 9y 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 9y 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/input/time 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
- nonsince 9y 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-poo-but-i-cant-write-my-name https://modelviewculture.com/pieces/i-can-text-you-a-pile-of...
  - gh02t 9y 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).
  - Majestic121 9y ago
    24h clock is very common in France, and other European countries as well
    - jszymborski 9y ago
      French Canada as well, and probably other members of the francophonie.
finalfantasia 9y 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/ https://www.mozilla.org/en-US/firefox/57.0beta/releasenotes/
ape4 9y 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 9y ago
  Modernizr detects supported input types: https://github.com/Modernizr/Modernizr/blob/master/feature-detects/inputtypes.js 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 9y ago
No week picker? Edge and Chrome implement it.
ajnin 9y 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.
482794793792894 9y 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.

265 points by abhinickz 9y 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 9y 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.
- Yaggo 9y 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.
fnord123 9y 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.
- Yaggo 9y 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?
  - DiabloD3 9y ago
    Most people intentionally set their locale wrong, to en_US, because a lot of apps simply do not have actual locale support, but try to do something when presented with a non-en_US locale.
    - NetMonkey 9y ago
      I know many like me, who also just prefers the application language to be in English. From decades of using English I have no idea what many terms are in my native language, native terms are much harder to google, and many applications are also poorly translated. But that doesn't mean I want everything in English, especially not date/time formats.
      - viraptor 9y ago
        Language and locale (how you want your date or numbers formatted) are two different things. You can set them separately.
        Piskvorrr 9y ago
        I can set them, all right. Somebody else then needs to read them, though...and has to take care not to assume that LANG===LC_TIME===LC_DATE. Sadly, I do not see that happening; in most cases, the apps are picking one locale setting, seemingly at random, and using it for all the other locale settings.
    - beejiu 9y ago
      I cannot remember an app that did not support dd/mm/yyyy format. It is the first thing a non-US English speaker will complain about.
      - fnord123 9y ago
        Last time I used Peoplesoft it had everything in American date format.
      - 9y ago
- babuskov 9y ago
  Agreed. ISO-8601 is the way to go.
- madisfun 9y 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.
  - fnord123 9y ago
    Yes I try to do that but I sometimes have used (accidentally) en_US in the past since I use ANSI International keyboard layout but GB locale settings.
_Codemonkeyism 9y ago
Didn't you know? There does not exist a world outside the US. We're all just illusions and bots.
Manishearth 9y 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 9y 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.
- jhasse 9y ago
  Works on Android though (or does the Play Stpre download a localized version for me?).
  - Manishearth 9y ago
    IIRC it does

mozumder 9y 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.

wruza 9y 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 9y 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 9y 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.
- Majestic121 9y 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.
Yaggo 9y 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.)
- metafunctor 9y 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.

abritinthebay 9y 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!

lucideer 9y 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.
- abritinthebay 9y ago
  Priorities I guess...
  - user5994461 9y ago
    I'd say localization.
    - scott_karana 9y ago
      Judging by the lack of format customization and Gregorian-only support, I doubt i18n was the delay. ;)
      - abritinthebay 9y ago
        To be fair - that covers all areas the ISO date format covers.
- bzbarsky 9y 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 9y ago

TIL you can render HTML from your address bar: data:text/html, [Your HTML here]

lucideer 9y 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/HTMLCanvasElement/toDataURL https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasE...
- oneeyedpigeon 9y 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.
  - Xophmeister 9y ago
    They can be embedded within a resource that is cached (e.g., an HTML page or CSS stylesheet).
    - oneeyedpigeon 9y ago
      True; I guess they're then beneficial if the resource is only ever used on that one page.
    - majewsky 9y ago
      For an example, see the SVG icons embedded in this CSS: https://fsfw-dresden.de/theme/css/fsfw.css https://fsfw-dresden.de/theme/css/fsfw.css (search for ".logo-twitter", for example)

dingo_bat 9y 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 9y 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 9y ago

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

wruza 9y ago
Adding date picker to platform after it lived through the peak of world-wide application development is big news itself.
MatekCopatek 9y 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 9y 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__ 9y ago
Agreed. You should really be able to fully style those inputs with bare CSS. Would make life so much easier!
- majewsky 9y 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.
  - amelius 9y ago
    That's why they should have written the controls in Javascript and put it on their CDN, or include it in the browser distribution. Then using the controls would only require a simple include in the head of the document, and you could style the controls just like any other HTML.
    - keganunderwood 9y ago
      No, push back against insane requirements. Why do we want to style input? Bill them for a custom solution if they want a custom solution.
  - dbbk 9y ago
    There are already ways to style native UI widgets, you can even style scrollbars...

oliv__ 9y 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 9y ago
> I hope it spreads to other browsers quickly. It is in other browsers for years
- reustle 9y ago
  Except Safari iirc :(
  - robin_reala 9y ago
    Or IE11: http://caniuse.com/#feat=input-datetime http://caniuse.com/#feat=input-datetime

claudius 9y 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.

majewsky 9y ago
Of course it won't. Public service providers in particular need to provide compatibility down to the likes of IE 7.
- yosamino 9y 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 9y ago

finally not only in chrome (and apparently opera)

mullsork 9y 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 9y 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 9y ago

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

MattBearman 9y ago
ISO 8601 (yyyy-mm-dd)
- moogly 9y ago
  No timezone part? Or UTC (w/ Z)?
  - Manishearth 9y ago
    No. It's up to the application to decide how it wishes to interpret timezones. Or if timezone should be a factor at all. E.g. if I'm booking a hotel you don't want it to pick up the user's timezone and frob that into UTC to send it over; you want the local hotel timezone. But if you're setting a calendar event you do want the timezone to be configurable, and you can add a picker for that. Assuming all time fields must have a timezone is why e.g. jekyll will re-date your prior posts (breaking all URL slugs) when you change your timezone.
    - moogly 9y ago
      > if you're setting a calendar event you do want the timezone to be configurable, and you can add a picker for that I suppose. In the product I'm current working, I guess technically we could add a TZ dropdown as you describe, but it'd go unused because the kind of events our users schedule, they want to use their current corporate local time always (there's no travelling across timezones involved for our users), and we need to know what time that is over here, so in lieu of one useful form field (UTC or datetime offset), we'd now have to send two (change the dropdown to a type=hidden), or another one with a "proper" datetime string. I guess not the end of the world[1], but it does introduce more opportunities for bugs. From what I've seen, few products have that timezone dropdown, and usually it tends to be an override that still needs a sensible fallback, and no information as to what timezone the current user is in gives you absolutely nothing. DateTime offset lets the application handle most cases, so that's what I prefer to use. [1]: also needs a timezone

ComodoHacker 9y ago

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

brucen 9y 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.
- mattmanser 9y ago
  You generally want the converse, the ability to block off Saturdays and Sundays.
  - brucen 9y ago
    Depends on the application obviously. A lot of social groups would likely be meeting once a week. It's just a simple example though of how the step function could be useful. For your example, you would just need a step with some kind of range. So you could say step=7, range=5 to allow them to pick from the first 5 days of every 7 (or to get trick step=7 range=-2 to eliminate the last 2 days). I'd hazard a guess they thought about this kind of stuff, but realised it would be complicated pretty quickly.
    - mattmanser 9y ago
      Most applications are enterprise apps, the vast majority of apps in the world today are enterprise apps. That work Mon-Fri, so want to restrict date pickers to Mon-Fri. And it doesn't have range, does it? So the infinitely more useful range hasn't been specified, but the almost useless step has. https://html.spec.whatwg.org/multipage/forms.html#forms https://html.spec.whatwg.org/multipage/forms.html#forms

pette 9y ago

This is not newsworthy. But will the inputs be mixed-reality ready?

amelius 9y ago

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

miguelrochefort 9y 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.
- amelius 9y 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".
  - miguelrochefort 9y ago
    I don't want software to be branded at all. I want all apps to look and behave the same, to the point where they're all just one app. Nobody asked for their shopping experience to be different when shopping on Amazon vs eBay vs Craigslist. I see no compelling reason to have different UI for services that are essentially identical.
    - felipeko 9y ago
      So, who gets to decide what it all look like? The broswer vendor? W3C? What if one browser does something others won't, and you can't do it custom, how do you get around it? Wouldn't that put us back to IE6 web? What if your site really needs something browsers don't have? Will we have sites telling us to install a plugin and put us back to Flash era?

Brosper 9y ago

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

mattmanser 9y 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.

yosamino 9y 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.
- mattmanser 9y 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).

gldalmaso 9y 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?

jhasse 9y ago
I wouldn't want websites to overwrite my locale setting like that.
- jeltz 9y 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.
  - jhasse 9y ago
    > (there is no API for a web server or JS to get the browser UI locale) There is: new Date().toLocaleDateString()
- Hussell 9y 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?

deleted 9y ago

[deleted]

giancarlostoro 9y 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 9y 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.
- 482794793792894 9y 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.

mdf 9y 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 9y 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.
- mdf 9y 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 9y 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 9y 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-microsoft-google-w3c-samsung-together-create-cross-browser-documentation-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/input/date https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

JCSato 9y 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 9y 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/input/date#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
482794793792894 9y 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 9y 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/input/time 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

nonsince 9y 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-poo-but-i-cant-write-my-name https://modelviewculture.com/pieces/i-can-text-you-a-pile-of...
- gh02t 9y 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).
- Majestic121 9y ago
  24h clock is very common in France, and other European countries as well
  - jszymborski 9y ago
    French Canada as well, and probably other members of the francophonie.

finalfantasia 9y 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/ https://www.mozilla.org/en-US/firefox/57.0beta/releasenotes/

ape4 9y 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 9y ago
Modernizr detects supported input types: https://github.com/Modernizr/Modernizr/blob/master/feature-detects/inputtypes.js 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 9y ago

No week picker? Edge and Chrome implement it.

ajnin 9y 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.

482794793792894 9y 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.