- Issue created by @sunlix
- Status changed to Postponed: needs info
about 1 month ago 11:11pm 26 June 2025 - 🇨🇦Canada joelpittet Vancouver
Thanks for reporting this. Could you clarify the underlying problem you’re trying to solve?
The issue summary explains that the markup changes and that a fieldset is used instead of the core’s default form-element, but it’s not clear what the impact of that change is. For example:
- Is the concern mainly visual consistency?
- Does the current structure break theming or accessibility?
- Are there usability issues with the new layout or behavior?
It would also help to explain how your proposed solution—using type="date" or datetime-local" while keeping the core markup—addresses that problem.
If possible, screenshots of the current vs. expected output or examples of where the new markup causes issues would make the case stronger.
Thanks!
Also note this issue may change the markup, depending on the outcome 🐛 Undefined array key "#type" in Drupal\Core\Form\FormHelper Active
- 🇩🇪Germany sunlix Wesel
Hey Joel,
thank you for your questions.
My personal feeling was only about the visual consistency. In the moment I tried this module my expectation was to get date / datetime filter with the usage of the webstandardstype
attribute.
As I saw that the module adds a additional fieldset element my theme broke, because it did not expect a fieldset in the views filter section.In the direct comparision above, the fieldset looks unnecessary. I didn't digged in to get a "why" the fieldset is there but maybe you have a clarification? :)
- 🇨🇦Canada joelpittet Vancouver
It shouldn't add a fieldset actually, I see you have twig debug turned on in your issue summary comments, could you add the comments for which template is loaded for the wrapper that includes the fieldset?
My guess is a theme is overriding
datetime_wrapper
, but not totally sure without that context. Thanks for following up.