inputmode or other hint to trigger "time" input method

[thw0rted]

This is a feature request to support a time value for inputmode.

I'll say up front, what I actually want is a time-only input where I have control over presentation format. This (slightly older) question suggests using <input type=text> with a custom pattern, but my issue is that this won't trigger an appropriate input method. This means that I can use <input type=time> but have limited control over what the user sees, or I can use <input type=text pattern="..."> and (presumably) the user gets a generic text keyboard to work with. If there's a solution for the first problem -- how to format the presentation of type=time -- I'd be happy to hear it, but I won't hold my breath.

That's why I'm opening this issue to address the second problem. As I understand it, inputmode exists to address needs like this. On mobile, this might present a clock-face input, or at least a number pad with period and/or colon characters as separator. I believe we need a new value, because while numeric or decimal could almost work, in many locales the colon is critical, but missing from the available inputs for both those cases.

Also: I found #3077, but it sounds like the end result was that inputmode will stick around. I also saw some remarks about not adding new inputmode values, but that was some time ago so I'm not sure if this stance has changed -- #3478 still hasn't been closed. So if you're still considering other candidates for inputmode, I'd like to see time as an option.

[thw0rted]

As an aside, if it's more likely to succeed, I'd be happy to open an issue to request more control over the presentation of <input type=time>, or maybe a way to override the locale with which a single input is rendered...

[annevk]

cc @dtapuska

[dtapuska]

From my understanding this is about overriding the user preference of how to input a time?

By default the time element uses the user's locale settings to determine if it should present a 24 hour or 12 hour clock. And it appears you always want to present a 24 hour clock is that correct? That doesn't mean that the user will understand what you want them to enter if they don't understand 24 hour notation.

On Android Chrome already prompts with the graphical system time picker. So I'm not certain there is anything really to do there.

[thw0rted]

Sorry if I was unclear. While I would appreciate what you describe -- a time element that lets me override locale settings -- it sounds like that argument has been done before, and will not be supported. (If you're open to rethinking that, I'd be happy to open a separate issue and discuss it there!)

Instead, in this issue, I'm asking for a property to set on <input type=text> that tells the browser to present the same input method it would normally use for <input type=time>. inputmode is the property you're supposed to use to tell the browser to use a specific input method, right?

The requirement that I have been given for the application I'm writing is to always show times in 24-hour format. The customer is military and they work exclusively with a 24-hour clock, regardless of how civilians in the area would localize time. Changing the platform locale is not an option (nobody offers a locale for "en-us, but with 24-hour time") so I'm following the advice I linked to above, and using <input type=text> with custom formatting / validation logic. The problem is that doing this prevents the browser from presenting the user with a friendlier time entry mechanism. So, I'd like to see <input type=text inputmode=time> so that users can get a "graphical system time picker" without the presentation constraints I would have if I just used <input type=time> directly.

[annevk]

I think if we added inputmode for time it'd still follow locale conventions. E.g., inputmode=email is going to present the alphabet of the user's locale.

[thw0rted]

I hadn't thought of that. I'm aware that, for example, some Android versions will pop up a "clock" interface to pick times, and might give two rings of numbers in a 24-hour locale (0-11 on the outside, 12-23 on the inside) versus a single ring for a 12-hour locale, with the option to tap "AM/PM" to toggle. I was really hoping to trigger a num-pad input with (at least) period and colon characters, since those are the commonly-used separators in this context. Maybe letting the user input a time with a 12-hour picker is still better than giving them an alpha keyboard, or a numpad without the colon character?

Would I be better served opening a separate suggestion to allow customization of presentation / locale on <input type=time>?

[annevk]

I'm not sure, you might also wanna review the discussion in #4180. In general implementers are somewhat lukewarm to invest here until there's a clear proven need and a way to implement the control in terms of some preexisting primitives.

[thw0rted]

Thanks for the link, #4180 clarifies a bit. Would it be better for me to close this issue and open a new one with a problem statement rather than a solution? I had not seen the FAQ, so I assumed that open ended issues that just say "My use case is X, and I think the current spec does not support it well" are too close to "Help, how do I do X?" -- which is of course a post best made to StackOverflow, not this tracker.

If I open a new issue, I would state the problem like this:

---

My use case is a military application, where users express time using a 24-hour clock, regardless of normal regional preferences. The requirement is for a form input:

• The backing value must be a time string in hours/minutes/seconds, with no attached date or time zone.
• The user must always be presented with a 24-hour view of the backing value, without regard for system locale / regional preferences.

---

Is that detailed enough to start a discussion? Is it too close to requirements that have been considered and denied previously?