The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: jorgefilipecosta <jorgefilipecosta@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

We're at least using a datetime field in the pages (site editor), so I checked that as well.

This matches the design specs, but I've noticed that interacting with the datetime-local input control (down), it opens a new calendar, which I find weird. Given the current setup, I think it'd be best to use a control solely for time at the bottom, rather than a datetime. Would you have any thoughts on this @jameskoster @mirka ?

It's a tricky one. The native browser calendar UI includes some tools which may (or may not) be useful like clearing the value, and a shortcut to select 'today'. It's also arguably more ergonomic on mobile. But on balance I think your suggestion sounds reasonable. Curious what @mirka thinks.

@jorgefilipecosta A couple of small feedbacks:

• In panel DataForms can we ensure the calendar grows horizontally to fill the container?
• If possible; in regular DataForms let's not show the calendar by default, just the datetime-local input is adequate.

If possible; in regular DataForms let's not show the calendar by default, just the datetime-local input is adequate.

We don't have a way to do this, both the panel and regular layout use the same underlying component declared by the field type (datetime). It also the same in filters. It'd be best to have the same control everywhere. If that doesn't work, we may want to look at how the form can set different controls for the field in a follow-up.

It'd be best to have the same control everywhere. If that doesn't work, we may want to look at how the form can set different controls for the field in a follow-up.

I suppose it doesn't matter, so long as a consumer can set up a date field in a regular DataForm that doesn't include the Calendar. Is that possible?

I suppose it doesn't matter, so long as a consumer can set up a date field in a regular DataForm that doesn't include the Calendar. Is that possible?

What I am hearing is that we need two controls, and we'd use one or another depending on the situation. We could have a:

• calendar-hour control, would render calendar (date) + input (only for hour).
• datetime control, would render the browser's datetime-local that handles both date and hour.

Any of them can be the default for the datetime field type, and individual fields can switch to the other as desired.

How does this sound?

If I recall correctly, we were mainly forced to build the custom calendar to show more intuitive visuals for date ranges. A custom calendar isn't really necessary (nor particularly "better") for a single datetime value, IMO. So I'd also think just an <InputControl type="datetime-local">, without our custom calendar, is adequate. Especially since in the context of a DataForm, it's more about manipulating values rather than nice visual presentation.

I actually wouldn't recommend the custom calendar + <input type="time"> combination, because not having a text-based input field for dates can be very annoying in many cases. It is often much quicker to change a digit in the month or year, rather than flip through a visual calendar to find it.

Reserving the calendar for ranges seems absolutely fine to me :)

Pushed changes to use the datetime-local:

This seems fine as a starting point.

I compared with the current date selection UX for posts/pages on trunk and I have to say there's something about the big calendar UI in the panel layout the feels really easy to use (as a mouse user). I appreciate there's a calendar UI built into the datetime-local input, but it's more fiddly to access. So I think it can still be worth exploring, but it's fine to do that separately.

@mirka how would you feel about a control that is basically a combination of calendar + input type="datetime-local" where selecting a date in the calendar just updates the date portion of the input value?

Thank you for pushing these enhancements @oandregal.

@mirka how would you feel about a control that is basically a combination of calendar + input type="datetime-local" where selecting a date in the calendar just updates the date portion of the input value?

Sounds good. Maybe this should just be the standard pattern for when using the custom calendar components. Pair with a datetime-local, and just sync the date portion with the custom calendar.

Size Change: +405 B (+0.02%)

Total Size: 1.94 MB

_{compressed-size-action}

Flaky tests detected in 8bdfe17.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/17736657466
📝 Reported issues:

• [Flaky Test] Redirection after template creation #60678 in /test/e2e/specs/site-editor/site-editor-url-navigation.spec.js
• [Flaky Test] correctly applies dynamic allowed blocks restrictions #51220 in /test/e2e/specs/editor/plugins/inner-blocks-allowed-blocks.spec.js