Datetime range min/max-width

Fixed the custom command failure errors in #2, thanks!

I tried reproducing this issue with Drupal 9.4, I am not able to reproduce the issue. the width of empty and filled date input field is same. Added screenshot for reference.

I tested this in 2 cases:

With the default Date Time module
Before: you couldn't save the content, but in the error you can see the problem

After: The problem is "fixed", but I think it is better to make the field bigger because it's cutting the last "y"

Created a custom code to make the end_date not required.
Before: when you edit for the first time you can't see the problem, but when you save it and edit again the problem is there.
After: The problem is "fixed", but I think it is better to make the field bigger because it's cutting the last "y" a little

I will change this to Needs Works because of the problem in the last "y".

As per Comment #8, increasing the min-width: 11.5rem, to show last Y. Adding patch for that and also adding Screenshot for reference.

#11 patch applied cleanly and working for me on drupal 9.5.

Patch #11 tested and reviewed on Drupal 9.5.x with Chrome, Firefox and Safari on Mac OS.

Looks good here!

Patch in #11 fixes the issue.
Before:

After:

Changing the status to RTBTC since there are 3 confirmations now.

+++ b/core/themes/claro/css/components/form--text.pcss.css
@@ -43,10 +43,10 @@
 .form-element--type-time {
-  min-width: 7.5rem; /* Prevent input width change while filling. */
+  min-width: 11.5rem; /* Prevent input width change while filling. */
 }

Why are we also changing the min-width of the time field?

Here's an updated patch for 9.5.x without altering the time field, just the date field.

@laurii Changed the min-width of the time field because the UI is not looking good with small width, so provide same width as date field.

Applied the patch #16 and it works. The time field is not altered, the date field has the same width if it is empty or not and the last "y" is not cut. Attached are the screenshots before and after applying the patch.

I tried reproducing this issue with Drupal 9.5.0, I am not able to reproduce the issue on my setup. the width of filled and empty date input field is same. i added screenshot for reference. Thank You

Verified on 10.1 and this issue is not reproducible for Claro theme. Date and time both have same width when filled and unfilled.
Please refer attached screenshot

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

This issue summary could be updated. What's the proposed solution, remaining tasks? Could use before/after screenshots since it's a UX bug.

Did not test.

Updated issue summary to point out that the issue can only be reproduced if viewing saved content. I was able to reproduce it. (also not sure it's something that needs to be changed, but that's just my take)

I am able to reproduce this issue with version 10.1.x-dev and I have created this patch it's working fine.

All the solutions proposed so far include setting min and/or max width. This is not ideal as different languages or accessibility needs can result in fonts/characters that occupy a different amount of space. No more min-width/max-width solutions please 🙂

You'll also notice that the dates themselves have the same width in each scenario. The difference is the spacing around the calendar picker icon - so that icon is what should be targeted in your solution.

A quick check of firefox shows the reported issue isn't happening there, so this looks to be a webkit thing. Just target the calendar picker icon in webkit:

[type="date"]::-webkit-calendar-picker-indicator {
    margin-left: -12px;
}

I applied the #29's suggestion.
Please review.

Moving to NW for the issue summary update to include the proposed solution. As #29 pointed out seems to be different approaches.

Cleaning up the issue summary by removing some irrelevant info and adding steps to reproduce, proposed solutions and additional remarks made in the comments.

Hope this makes it somewhat easier for others/maintainers to review this issue.

Re #29: I do see the problem in Firefox (v112 on MacOS) too, albeit slightly more subtle. See the screenshot comparison in #34 and the issue summary.

The space difference in Firefox screenshot looks like normal character width variation that is inherent to non-monospaced fonts. The “mm” being wider than “05” is expected behavior, not anything that should be addressed with a code change.

And while the reported issue isn’t particularly consequential either, the margin difference with the indicator does not seem as-expected and adding css to address it would be justified.

Applying a negative margin proposed in #29 does seem to do the trick. And I agree it's a better solution than increasing the min-width to an arbitrary value.

Either way, I'm not really sure how I feel about having to solve what is basically a bug/quirk in Chrome. Are we okay with solving it this way - and perhaps having to roll back this styling if one day Chromium does fix this on their end?

P.S. Here's a codepen to test this outside of Drupal: https://codepen.io/Tinto/pen/XWxZGOx.

Either way, I'm not really sure how I feel about having to solve what is basically a bug/quirk in Chrome. Are we okay with solving it this way - and perhaps having to roll back this styling if one day Chromium does fix this on their end?

That's a good point! There is precedence for making this kind of change to account for a browser quirk: We find (or potentially file) the issue to the issue tracker of the browser in question, then apply a fix with a @todo pointing to the browser issue and instructing to remove the fix when that issue is addressed. It usually takes a few years after the problem is addressed to remove the Drupal fix, but it's also not problem causing code so it's fine having it hang around.

However I should also mention that any time I've seen this approach it has been for an issue that is a little more consequential than the one reported here, but if someone were to track down the info needed to make an appropriate @todo, I'd still be fine RTBCing or committing.

Interesting! The only related chromium bug I could find is this one: https://bugs.chromium.org/p/chromium/issues/detail?id=1090500. It was fixed almost three years ago and does not seem to cover our issue 100%.

What caught my eye was a suggestion in one of the comments to limit the whitespace by using margin-inline-start: 0 on the calendar picker pseudo element. Setting this value to zero does not fix our issue, but setting a negative value renders the same effect as #29.

My proposal is to set a negative margin of 0.875em (14/16), so that it plays well in case the font-size is overridden for some reason. So looking at the current code, I would add this to /core/themes/claro/css/components/form--text.css:

.form-element--type-date::-webkit-calendar-picker-indicator {
  margin-inline-start: -0.875em;
}

If we can get consensus that this is the best possible fix, I can write a patch.

@bnjmnm: should we still open up a new issue for Chromium and add a comment in the patch that refers to that issue?

Adding patch as per #40

Hi guys, looking into this in DrupalCon Singapore 2024 as a novice & first-time contributor.

Patch #42 applied cleanly on Drupal 10.3.10 and solves the problem.

Created a MR as per #42

Hi i have tested the MR from #47 its working fine for me.

step followed --
1. enable date module
2. added date range field to any content type
3. create node using that content type
4. fill all field only leave the date one empty

Result--
the node saves fine without form validation error.

MR worked for me RTBC+1

Nice work everyone! Happy to see this moving forward.

Perhaps nitpicking on my part, but do we need to address the suggestion mentioned in #39?

apply a fix with a @todo pointing to the browser issue and instructing to remove the fix when that issue is addressed

Left feedback in MR
I'm not sure the review in #48 looked for the style issue reported, but instead was seeing if something could save?

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. 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.

The Claro theme was approved for removal in #3576460: [policy, no patch] Deprecate and remove Claro.

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

The deprecation work is in #3576668: [meta] Tasks to deprecate Claro and the removal work in #3584638: [meta] Tasks to remove the Claro theme.

Claro has moved to contrib