Software customers often want other date formats besides the default, such as “mm/dd/yyyy”. It’s difficult do to it cleanly with the existing HTML5 standard. A quote from a Reddit discussion:
<input type="date" sequence="mdy" separator="/">
It’s not perfect, but covers the vast majority of variations desired. “Sequence” tells which element goes in which order, and “separator” tells which separation character is expected.
Addendum: Existing HTML5 code would still work as it did. The proposed attributes are optional. In other words, if you leave out “sequence”, it defaults to “ymd”; and if you leave out “separator”, it defaults to “-” (dash).
It’s a bit unclear here what the “customers want it a certain way” part really gets at. Surely, for anything involving a form that then submits data to a database or similar, there’s server-side code that catches what is sent and then acts on it. That server-side code can grab the value sent by the date input and manipulate it any way it sees fit. The only time I could imagine raw form data being used directly/exposed to the customer raw without any further processing would be something like a form that simply/dumbly sends an email of all the field values that were received, with no further processing. And again there, a simply extra bit of server-side processing is all that’s needed.
In short, I’m not seeing/understanding what the actual use case is this would solve.
Patrick, it’s the user’s input side that is the main concern I’m focusing on. Let’s just consider what the user sees for now. I agree that server processing can readjust as needed for the database etc. It might be nice to have better control over that, but that’s a different issue.
Right now the user input side formatting is inconsistent across browser brands, and that appears to be because the standard is either fuzzy on that or explicitly leaves it up to browser vendors. But if one wants the displayed input format for a particular application or particular input box to be a specific way, there is no standard way to control that. And this includes validation, not just display. For example, “12/33/2020” should be rejected (fail validation) but “12/31/2020” pass, when the desired format is activated.
Ah, so this is more about how the input manifests itself to the user / the widget that the browser presents. In theory, I thought the idea was that the browser can/will take the user’s locale into account to show an appropriate format and a platform-specific calendar type widget, but yes on platforms that currently just show a text-like input, I can understand how expecting a particular set format that isn’t appropriate/matches the way a date is entered in the user’s locale can be problematic. Thanks for clarifying.
I understand the theory, but found it too idealistic in many cases. For one, if the local is wrong or not as intended, many users wouldn’t know how to change it in their browser or operating system. Second, frequent business travelers may have to use the same software all over the world on different computers. Such unexpected input format changes would be confusing and annoying. Having the input format be optionally controllable per field and per app (via CSS) allows developers/designers to fit a particular organization’s input needs and conventions.