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.
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
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:
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).
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
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.
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.
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.)
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.
> 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.
You could implement the locale-less Intl.DateTimeFormat or Intl.NumberFormat such that they get the current formatting settings regardless of locale data.
Here's the problem: given that I have already configured date and time formats (among other things) in my operating system, like everybody else has, how do I access those settings and pass them on to DateTimeFormat?
The browser ought do that automatically, that it does not is the issue at hand. I was just pointing out that the Intl API does not seem to preclude implementing this behaviour, it still needs to be implemented. Which first means that it should be reported to Firefox's bug tracker (I have not seen a single link to FF's bugzilla in any of the subthreads).
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.
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):
http://longnow.org/about/ "The Long Now Foundation uses five-digit dates, the extra zero is to solve the deca-millennium bug which will come into effect in about 8,000 years."
Based upon human stubbornness, every planet will have it's own time and date system that will be divided based on historically obscure details before/during and after colonization. Stuff like Thursday is essentially "Thor's day" and in German it literally says "day of the thunder" (Donnerstag).
ps.: Thursday is also Jupiter's day, so it will probably prevail on any colony / permanent human station orbiting it/it's moons.
pps.: I hope they get over the stupid imperial vs. metric divide though.. that one is really annoying.
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.
No, the US has no official language at the federal level:
" English is the official language of 32 states; English and Hawaiian are both official languages in Hawaii, and English and 20 Indigenous languages are official in Alaska. Algonquian, Cherokee, and Sioux are among many other official languages in Native-controlled lands throughout the country. French is a de facto, but unofficial, language in Maine and Louisiana, while New Mexico law grants Spanish a special status."
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.
> 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.
I am bilingual myself, and I strongly prefer each context to be self-consistent. When reading English text I find Norwegian date formatting confusing, and vice versa. I routinely have open tabs in different languages.
Which is OK (so the user should have a choice :) ). Just my personal experience, but seeing dates as "06/07/20XX" always makes me do a double check (is this next week or in a month?) unless I know that I have everything configured my way, which may be different from the way of site designer.
Because all dates in paragraphs and tables will use the Norwegian date format while forms will use the date format of the visitor. Having two date formats on the same page can be very confusing, especially if one is D/M/Y and the other is M/D/Y.
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?
I build Danish self service web applications, and from my perspective I would always want to control that date formats fits the displayed language.
Why must it then be in Danish? Because we would rather optimize for Danish users who for some reason have gotten the wrong browser version / localization settings and don't know how to change it.
An English speaking user would be much better served with a dedicated English version than just the date format being correct - if they can overcome the language barrier, surely they can overcome the date format.
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.
It is important that a Norwegian visitor with a browser configured to prefer en-US [1] would see the entire web page in the same locale. Why should _parts_ of the web page localize to a different locale than other parts?
The standard Norwegian date format is DD.MM.YYYY, _easily_ confused with MM/DD/YYYY. Why is it a feature to include this confusion?
[1]: This is pretty common, either deliberately or by accident. If you actually want to serve content localized in multiple ways (eg. you want to serve both an English and a Norwegian version) you have to sidestep browser localization anyway and offer the user a way to select which version they want.
> It is important that a Norwegian visitor with a browser configured to prefer en-US [1] would see the entire web page in the same locale. Why should _parts_ of the web page localize to a different locale than other parts?
Completely agree - that should not happen. Consistency is most important. So if a Norwegian user has an en-US browser and the rendering uses this control which uses default browser locale then all date rendering in all markup has to be en-US. That is: this control can't be used on a web site unless the site already uses browser locale for all date input and output.
If the web page already has custom date formatting (e.g. the user chooses locale/format in the site preferences) or if the page has elements rendererd DD.MM.YYYY already from the back end - then this control can't be used.
(Also: TIL Norway doesn't use ISO 8601 like Sweden. I honestly thought ISO 8601 was norm in Europe, but apparently mostly in Sweden).
According to [1] Sweden uses SS-ISO 8601 and Norway uses NS-ISO 8601.
According to [2]: "All members of CEN[3] (all of Western Europe and Scandinavia, and most of Eastern Europe) are required to adopt the EN 28601 European Standard. Most have now done so"
I think [1] only covers how ISO is used in norway. I think if you look at what's actually common you'll find that norwegians use the non-ISO dd.MM.yy most of the time, but when they use ISO they use ISO as in [1] above.
That's the difference to sweden, we'd actually us an ISO 8601 type format as our everyday format.
You're confusing language and locale and that's going to be equally confusing to your users.
I read web content in several languages and expect date formats in ALL applications my application to follow my OS locale which is Finnish.
My Windows operating system is in English, yet my locale is Finnish, so that the date format is Finnish. This is the standard way of using locales. Why would web sites be any different?
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’.
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!
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.
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.
For the same reason sites end up implementing language switchers despite your browser having a way to set your preference and send it in an HTTP header.
Huh? How is a localization being tied to a browser bundle vs OS remotely the same as a website offering the ability to view content in different languages?
I can change my OS locale settings just by opening up a panel. Firefox wants me to install a new official locale or a new browser bundle to do the same.
Btw, content language is not a locale preference, it's contextual. Browsers could have a standard dropdown in their UI to change that header on the fly, sure, but that wouldn't make language selection unnecessary. Take something like Wikipedia, the contents are widely different across languages, and switching is common for multilingual readers.
The common reason here is that among people who aren't the sort to post on Hacker News, knowledge of how to change these things -- in the operating system for locale, in the browser for preferred languages -- or even knowledge that these things can be changed, is uncommon.
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.
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.
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.
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.
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?
That's a problem we already deal with by having labels for the date inputs which explain the expected format. This is especially necessary in Canada, where until recently there was no recommended format, and the government recommendation isn't even well known yet much less universally used. So, depending on what part of the country you live in, you'll expect a different date format, even though you're technically using the same locale.
So, to do what you want, I'd have to make different versions of all the supporting documentation for each possible date format, and then get each version translated.
Also, displaying the dates the user just entered in a different format is a usability problem. (Users will complain. A lot.) So, if I did what you want, I'd likely be asked to display all dates, everywhere on the site, in the format the browser happened to be compiled with. This is possible for dates in the database, but not so much for dates in static content like news releases.
Just to be clear: I have no objection to making it easy for a website to have date input widgets which use the user's locale. I just want it to be equally easy for a website to have date input widgets in a specific locale. For example, how am I to make a website comparing date input widgets for different locales?
> So, to do what you want, I'd have to make different versions of all the supporting documentation for each possible date format, and then get each version translated.
??? I'd never said that I wanted a label explaining the date format for me.
> For example, how am I to make a website comparing date input widgets for different locales?
The input widgets return ISO 8601 regardless of the locale. Or what do you mean?
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.
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.
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.
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.
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.
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.
And oh the fun you'll have when you try to use a keyboard! (Nope nope nope, everyone clicks, you with the keyboard don't matter, and you with the screenreader just go away already)
The idea is that you are using the native field to listen for user events, so the ux shouldn’t change. You have to proxy click events since the element isn’t visible, but key presses work as usual.
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.
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.
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.
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.
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.
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).
> First things first: I'm talking about the date picker
But then why are you complaining about the timezone ? A datepicker doesn't need a timezone.
Or are you under the impression that ISO 8601 requires a Time component?
In case you are, you are mistaken: ISO 8601 requires no Time. "2017-10-23" is perfectly valid according to ISO 8601 and it's also precisely what is submitted by the browser.
I don't really understand your comment about the specific allowed time format. It's obvious that every application will have different validation-
requirements, that doesn't negate the usefulness of having a dedicated time input. Especially on mobile, getting a simple native time input widget seems like an advantage for many cases. If it doesn't work for your use-case then just don't use it. It exists to support, and if you already have a solution that is better, that's good, no?
EDIT-start I wrote this next part not realizing that the UI for the timepicker is not enabled in this version of Firefox, please ignore.
But just for completeness sake, you can let users enter increments of [00, 15, 30, 45] like this:
<input type="time" name="time" step="900" />
The value 900 comes from 15 times 60 seconds.
EDIT-end
As for your comment about my mention of javascript, I think you overread that I wasn't advocating "mucking around" I was merely pointing out the context of a serverless javascript application.
It doesn't require it, that's the ambiguity. Damn, I find you frustrating. Are they just sending yyyy-MM-dd or are they adding 00:00:00. Or worse 00:00:00Z. Or even worse 00:00:00+0700? They don't say! It's the most important functionality of the date picker and the author, who was probably the developer, seems unaware of how critical spelling out the exact response type is.
We're talking about a FORM control, a fundamental HTML technology that doesn't need JavaScript enabled. We're talking about specific implementation of a spec that they didn't spell out, skip over as if it didn't matter, and could alternately make the control brilliant or utterly useless.
And no, it's not good that they add an inflexible, broken, time control that you have to type and almost no-one will be able to use. Because now they won't try and make a decent one.
Yes! If they say that a date is to be in the ISO 8601 format, a reasonable person would assume that this means the ISO 8601 date format.
> or are they adding 00:00:00. Or worse 00:00:00Z. Or even worse 00:00:00+0700?
No! That would be the ISO 8601 datetime format! Why would you assume that they would use the datetime format for a date?
> They don't say!
If they said that dates are converted to RFC 2822 format, would you be griping about whether they were sending yyyy-MM-dd@hostname.tld? No, because it would be obvious from context that it means RFC 2822 date format, not RFC 2822 address format.
Maybe there is a little bit of potential for confusion, because they say "All dates and times will be converted ...", rather than making separate statements for dates and times. But when they say "as specified in the [spec](hyperlink-to-the-spec)" 4 words later, a reasonable person might head over to that spec to clear up any confusion or questions about the behavior.
> We're talking about specific implementation of a spec that they didn't spell out, skip over as if it didn't matter
The did spell out the spec! They included a direct hyperlink to the spec; that link was even in the part that you quoted. And since when is a blog post expected to spell out every little thing that is included in the spec that it's talking about? Especially when every third paragraph says "as specified in the spec" with a link to the relevant page in the spec?
> 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).
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.
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.
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.
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.
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...
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.
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.
> 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?
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.
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.
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.
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.
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.
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.
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.
> 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. :)
> 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.
Apart from Xophmeister's point about embedding within a cached resources, two other use-cases:
1. generated or dynamic resources - e.g. displaying an image from a file input before it's uploaded to a server
2. reliability - e.g. Github's 404 page[0] uses them to ensure the entire page source is standalone and works independently of other services/resources.
It's very common to do as part of a compiling/deploying step, for shared files like css or js, very rarely done manually (maybe for very very small icons).
E.g. I use url-loader in webpack to do require('./some_image.png') and that's converted to a data URI if the image is small enough (otherwise I get a regular URI). The output is a .js file shared among all pages of the site.
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.
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.
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.
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.
> 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.
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.
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.
> 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".
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.
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.
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.
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.
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?
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).
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.
> 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.
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.
> 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.
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.
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.
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