Datetime and Datelist elements should render as fieldsets

Can we re-base the MR on 11.x?

Don't have time to actually rebase but updated target.

I rebased the MR. It was not really possible at first because there were merge commits in the branch. Luckily it was pretty straight forward to get rid of the merged commits because there were no merge commits before the MR commits. I rangit reset --hard a9d6facb4e, where a9d6facb4e was the last commit before the commits that were introduced by the merge commit. After that I could run git rebase 11.x without any difficult conflicts to resolve.

Thanks for the review @rkoller! I'm wondering if you've tested the experience before this patch? It would be helpful if we could figure out how the experience changes as the result of this issue, so that we know which issues needs to be tackles here, and which issues should be moved into their own bug reports.

It looks like I mentioned this already in #38, but putting it again here for visibility. Instead of just removing the datetime_wrapper from drupal_common_theme(), we need to deprecate it. Unfortunately we haven't defined the steps for this 📌 Provide a mechanism to mark entire twig templates as deprecated Fixed so this is something we'd need to come up with.

Here's the current state of the MR as a patch file for stable use in composer builds. This applies for me on 10.2.4.

Adding note on "current" behaviour for Drupal 10.2.5 with Claro admin theme.

I have a custom entity with 2 fields:
- BaseFieldDefinition::create('timestamp')
- BaseFieldDefinition::create('timestamp')

When rendering by Drupal\Core\Entity\ContentEntityForm, they appear as such:

However, changin the definition to BaseFieldDefinition::create('datetime') and clearing the cache:

Not sure if current MR/patch updates 'timestamp' too, but I would expect them to both display the same.

I've updated the patch for Drupal 10.3.1

anish.a → made their first commit to this issue’s fork.

I was trying to rebase with 11.x. Some functions are deprecated. Not sure which way should I go to fix this.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

acbramley → changed the visibility of the branch 3078334-datetime-and-datelist-95x to hidden.

acbramley → changed the visibility of the branch 3078334-datetime-and-datelist-945 to hidden.

acbramley → changed the visibility of the branch 3078334-datetime-and-datelist to hidden.

I've merged 11.x into this branch and resolved all conflicts. I've reverted some of the code that removed datetime_wrapper theme hooks and preprocessing and I think we need to add the templates back as well and deprecate that properly.

Has the datetime-local element been considered as replacement for some of these scenarios? If there's a time element, this option is a much better UX to eliminate wrappers. Theres a few related patches that fix a few datetime-local issues.

There are a few browser compatibility issues for datetime-local with safari & firefox not showing the time picker but time can still be entered. Is that a deal breaker?
Internet Explorer doesn't support it all. Do we still care about IE?

For just dates, a custom element that extends Datetime would work that just removes the theme wrappers and replaces the date title with the element title. The only one that should get a fieldset wrapper IMO is the date list widget if we could adopt datetime-local.

I've reverted some of the code that removed datetime_wrapper theme hooks and preprocessing and I think we need to add the templates back as well and deprecate that properly.

I added the templates back and added a deprecation.

And I drafted a change record: https://www.drupal.org/node/3530128 →