Claro datetime range min/max-width

Created on 30 November 2021, over 3 years ago
Updated 19 January 2023, about 2 years ago

Claro datetime range min-width is causing "empty" fields (containing dd/mm/yyyy placeholder) to be wider than filled fields. See image.

Added this.
max-width: 11rem; /* Prevent empty input to be wider than filled input. */

See patch for details.

๐Ÿ› Bug report
Status

Needs review

Version

10.1 โœจ

Component
Claroย  โ†’

Last updated 4 days ago

Created by

๐Ÿ‡ณ๐Ÿ‡ฑNetherlands Drumanuel

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Status changed to Needs work about 2 years ago
  • ๐Ÿ‡บ๐Ÿ‡ธ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.7
    last 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 rpayanm

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

  • ๐Ÿ‡บ๐Ÿ‡ธ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.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States bnjmnm Ann Arbor, MI
  • ๐Ÿ‡ณ๐Ÿ‡ฑ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?

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia karanpagare

    Adding patch as per #40

  • ๐Ÿ‡ธ๐Ÿ‡ฌ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.
  • Merge request !10536#3251976: date-time-claro โ†’ (Open) created by Unnamed author
  • Pipeline finished with Failed
    3 months ago
    Total: 630s
    #366320
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia ahsannazir

    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

  • ๐Ÿ‡ณ๐Ÿ‡ฑ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

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States bnjmnm Ann Arbor, MI

    Left feedback in MR

  • Pipeline finished with Failed
    3 months ago
    Total: 228s
    #369466
  • 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.

  • Pipeline finished with Failed
    3 months ago
    Total: 643s
    #374558
Production build 0.71.5 2024