Update TimePicker component design

[jameskoster]

Extracted from #64267 (comment)

TimePicker was originally designed with a fairly narrow scope; the date picking UI in the page inspector:

In this context (popover) there is room enough for a more elaborate UI with multiple controls. However in a more traditional form setting this design is convoluted and overly prominent. Let's explore a more lightweight design, applicable either as a variant or a full redesign.

Inspiration can be taken from the datetime-local input type which condenses everything into a single text field with a built-in calendar/time selection popover:

[mirka]

Possibly related: #60971

[seifeldinio]

Here's a suggested design update for the TimePicker component.
In the new design, I’ve taken into consideration the need for a more lightweight and streamlined UI.

Here's a prototype to showcase the updated design in action:

demo.mp4

Component:

Mockup:

Would love to hear your thoughts!

[christopherabalos]

While I agree that TimePicker feels heavy, the separate controls also ensure accessibility. Calendar and time controls are two of the most difficult UIs to make accessible.

The native datetime-location input type allow selection of each date/time segment:

Something similar would need to happen in an updated TimePicker.

[jameskoster]

@christopherabalos absolutely, 100%! I think the first step here is to assess the accessibility of the datetime-location input type, and how much of that should be embodied 1:1 in the updated design.

From there it'll mostly be a case of applying the wp design language to the visuals, as @seifeldinio did above.

It's worth keeping date range picking in mind as well (#60971 as pointed out above), with additional shortcuts for things like "Last week", "Month to date", etc. This will be useful for filtering data views (e.g. to show pages published in the last month).

[mirka]

Might be stupid question, but what is stopping us from just using the native <input type="datetime-local"> (or <InputControl type="datetime-local">)? Especially when we want to shift to this "popover" style. A recent accessibility test said that "its overall experience surpasses any other custom date picker I’ve encountered on various booking platforms". And we get a ton of stuff for free, like mobile support.

Even for the date range picker case, I find it likely that the easiest way to build that accessibly is to use two native datetime-local inputs, rather than going for a custom or library solution.

[DaniGuardiola]

@mirka I would push for using the platform for these things every day of the week, for those same reasons. Unless there's a very specific, very critical requirement or constraint to not do that, I feel like these days it's the best option in almost every aspect, at the cost of slightly less design freedom.

[jameskoster]

I lean in that direction as well, and had the same thought about combining two native datetime-local inputs for the range picker. A detail missing there would be shortcuts for quick selecting presets like 'Month to date', 'Last week', etc., but that can be discussed in #60971 and a design solution seems trivial on the surface.

As Dani points out the main drawback is styling; making it blend seamlessly with the broader UI may not be possible. That is arguably an acceptable trade-off though; there are too many benefits to ignore. The mobile experience in particular is really slick... getting all of this for free, without having to worry about the ongoing maintenance feels like a huge win:

[DaniGuardiola]

@jameskoster glad to see some agreement! FWIW, there are some ways to still get the design closer to what we want, mainly:

• https://developer.mozilla.org/en-US/docs/Web/CSS/accent-color
• https://developer.mozilla.org/en-US/docs/Web/CSS/color-scheme

Not sure if they apply to these specific input types though. I would assume they do or, at least, they will at some point.