Hi, I'm very pleased with the usage of this lib, but I would like it if it was possible to have a "clear" button ❌ on the widget when a date is already set. What do you think ?

So that they can all be localised or tweaked invidivually.

For example:

The controller adds some actions itself to avoid the user having to add them in their markup.

However these have the name of the controller hardcoded. For example:

This means a child controller won't work properly.

Basically the title-- is it possible to have the calendar automatically show and hide based on the text field focus rather than a click?

Context: Using Zurb foundation CSS framework in XY grid mode which has proved concise and useful.

However, using a browser emulation of mobile terminal (both Chromium and Firefox) the calendar goes off the deep end with

fit-content
Doing a modification to the CSS

.sdp-cal {
  max-width: fit-content;
==>
.sdp-cal {
  max-width: 100%;

now occupies reasonable space. But the dropdowns are now rendering EACH to full-width of div

with the size matching the emulated browser window width

Note: I have also tried to exclude the div for the calendar entirely from the XY grid, but leading to the same result

With the style forced upon the tag, I cannot see how can this be overcome ?

A user reported that they were unable to dismiss the calendar.

Their steps to reproduce:

1. Click the calendar icon to open the calendar.
2. Click on another date.

Expected: the calendar disappears and the text input changes to show the clicked date.
Actual: the text input changes but the calendar does not disappear. Neither clicking the calendar icon nor clicking elsewhere on the page has any effect. At this point pressing F12 does not open the developer console. The JavaScript console does not show any errors.

Firefox 105.0 (64-bit) on Ubuntu 18.04.

For example: set min date as 2022-05-01 and navigate to April.

Now both the keyboard navigation and the mouse navigation is broken.

Currently, Event('change') is being dispatched by selectDate after setting dateValue. However, dateValueChanged (a Stimulus callback) sets the actual input value. This means that the 'change' event is being triggered before the input value has actually changed, which may be unexpected for those who have registered eventListener(s) on the input element.

Does it make sense to move the dispatch to dateValueChanged?

Seems to be the way the wind is blowing.

Any time I use the datepicker to pick a date before 2000-01-01, the input element does not display the date. This happens on the demo page too.
https://airblade.github.io/stimulus-datepicker/

If I provide the input element with a value like "1999-12-31", I can briefly see the text inside the input element before it disappears again.

<!-- good -->
<input data-datepicker-target="input" type="text" value="2000-01-01" name="user[birthdate]" />

<!-- bad -->
<input data-datepicker-target="input" type="text" value="1999-12-31" name="user[birthdate]" />

In order to look a little cleaner, the month and year <select>s have appearance: none and a custom down-arrow.

However there are a few problems:

• For months with shorter names, the arrow is far away from the name.
• The arrow is not clickable.
• The focus ring encompasses the name only, not the arrow, and doesn't have enough padding.

• The columns have no space between them.
• The page would look better with some padding.

Use case: only weekdays / business days can be selected.

And also add a CSS class for weekends.

I think the vast majority of dates which crop up in webapps fall into two categories:

• near dates: within a year of the current date and usually within a few weeks;
• far dates: more than a year away; e.g. an adult's date of birth.

These categories pull the UI in different directions. For example, for a near date it's better to have only previous-month and next-month buttons. There's no need to have a month dropdown or a year dropdown. For a far date, you probably want some kind of decade chooser, and after the user has chosen a decade something like the current datepicker with a year dropdown covering the decade.

A datepicker which tries to cover both near and far dates is not going to be great at either. This is the datepicker at the moment.

The main benefit of a datepicker is the presentation of dates in a calendar. This is useful for near dates when the target date probably has some relation to the current date, and the day of the week is probably relevant. A calendar is not nearly as useful for a far date, where you most probably don't know or care about the day of the week, nor need to click through previous and next months.

Therefore it makes sense for a datepicker to optimise for near dates. If the user needs to enter a far date, they should be given simple year, month, and day dropdowns, or a text input which can parse what they enter (which this datepicker can do 😉).

Therefore I plan to replace the month and year dropdowns with static values.

It could be argued that the month and year dropdowns are working fine, and provide some flexibility for jumping to different months or years, and don't complicate the UI much. But I'd rather the datepicker were really good at one thing (near dates) than quite good at near dates and OK at medium (not near and not far) dates.

They are clipped or distorted somehow.

E.g. for public holidays.