- Status changed to Needs work
about 2 years ago 10:03pm 14 February 2023 - ๐บ๐ธUnited States smustgrave
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.
- ๐บ๐ธUnited States bnjmnm Ann Arbor, MI
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)
- First commit to issue fork.
- Open on Drupal.org โEnvironment: PHP 8.1 & MySQL 5.7last update
almost 2 years ago Not currently mergeable. - @dsandhya opened merge request.
- ๐ฎ๐ณIndia dsandhya
I am able to reproduce this issue with version 10.1.x-dev and I have created this patch it's working fine.
- ๐บ๐ธUnited States bnjmnm Ann Arbor, MI
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; }
- First commit to issue fork.
- last update
almost 2 years ago 29,378 pass - @rpayanm opened merge request.
- last update
almost 2 years ago Custom Commands Failed - ๐บ๐ธUnited States smustgrave
Moving to NW for the issue summary update to include the proposed solution. As #29 pointed out seems to be different approaches.
- ๐ณ๐ฑNetherlands tinto Amsterdam
Cleaning up the issue summary by removing some irrelevant info and adding steps to reproduce, proposed solutions and other relevant info.
Hope this makes it somewhat easier for others/maintainers to review this issue.
- ๐ณ๐ฑNetherlands tinto Amsterdam
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.
- ๐บ๐ธUnited States bnjmnm Ann Arbor, MI
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.
- ๐ณ๐ฑNetherlands tinto Amsterdam
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.
- ๐บ๐ธUnited States bnjmnm Ann Arbor, MI
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. - ๐ณ๐ฑNetherlands tinto Amsterdam
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%.
One of the comments suggests limiting 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 does. It renders pretty much the same result 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 small patch.
@bnjmnm: should we still open up a new issue for Chromium and add a comment in the patch that refers to that issue?
- ๐ธ๐ฌSingapore stuckinconcretejungle
Hi guys, looking into this in DrupalCon Singapore 2024 as a novice & first-time contributor.
- ๐ธ๐ฌSingapore stuckinconcretejungle
Patch #42 ๐ Claro datetime range min/max-width Needs review applied cleanly on Drupal 10.3.10 and solves the problem.
- First commit to issue fork.
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 emptyResult--
the node saves fine without form validation error.MR worked for me RTBC+1
- ๐ณ๐ฑNetherlands tinto Amsterdam
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
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.