useCalendarCell equates "outside of visible range" with "disabled".

[rglazebrook]

🐛 Bug Report

useCalendarCell returns true for isDisabled when calendar dates are outside the visible date range (i.e. isOutsideVisibleRange is true), but are still within minValue and maxValue, and are not passed an isDisabled prop. This is preventing click/press events on those dates.

🤔 Expected Behavior

You should be able to click on dates that are outside the "visible" date range of the current month, but aren't otherwise marked as unavailable or disabled. This would mirror the behavior in the native HTML5 datepicker.

😯 Current Behavior

Dates outside of the visible date range are being marked as isDisabled internally. This prevents any of the click/press events from firing. Based on the description of isDisabled , I believe this could be a bug.

E.g., If I'm looking at June 2022, July 1st can be made visible, but cannot be made clickable (because it is being marked internally as isDisabled). However, July 1st is enabled and clickable from the July 2022 calendar.

💁 Possible Solution

Dates outside of the current month should not be marked as isDisabled. From a styling perspective, we still have isOutsideVisibleRange to work with, and the dates would still be properly disabled if they fell outside of the min/max values.

If this is expected behavior and changing this would constitute a breaking change, adding a calendar-level prop something like disableOutsideVisibleRange and defaulting it to true would provide users a viable workaround.

🔦 Context

I am trying to replicate behavior found in the standard HTML5 datepicker, wherein selecting a date from the previous/next month, if it is visible in the calendar, is possible. My goal is to not lose features when switching over.

💻 Code GIF Sample

Here's a GIF of my implementation of useDatepicker, useCalendar, etc:

And here's an example of the same behavior with a standard HTML5 <input type="date" />:

🌍 Your Environment

Software	Version(s)
react-spectrum	3.0.0
Browser	Chrome
Operating System	macOS Big Sur

🧢 Your Company/Team

N/A

🕷 Tracking Issue (optional)

N/A

[devongovett]

One problem with this design is the dates still look disabled visually (grayed out). If they are interactive, they'd need to meet WCAG contrast minimums as well to be accessible. Not to say we shouldn't support more control here though.

[garand]

I'm also running into this with my implementation. From an a11y perspective, I think determining how to style the out of range but enabled options would be left to the user, but I agree they should be clickable. They are focusable, however focusing will trigger a focus of the next page.

[devongovett]

I think this would need to be opt-in but does seem like something we should support. I see three main use cases:

1. Dates outside current month are hidden (possible currently).
2. Visible but greyed out and non-interactive (possible currently).
3. Visible and interactive (not possible).

Reason it must be opt-in is so that we don't have hidden and/or low contrast elements that are interactive unintentionally.

Behaviorally, the easiest thing to do would be to make them simply non-disabled and focusable. However, the current behavior when navigating with a keyboard is to switch to the next/previous month when navigating to a date outside the current month. Would this be what expected or would you only expect to switch months when navigating to a date fully outside the view?

[garand]

I would expect the current focus behavior but be able to click dates outside of the current month.

[ingro]

I support this change, at least a configuration prop to follow the behaviour of the native HTML5 datepicker will be very welcome!

[Drogglbecher]

I face the same problem while trying to implement a DateRangePicker based on the RangeCalendar. Is there currently any status update or workaround?

[GregorGabric]

any updates?

[arzatskis]

Want to introduce react-aria-components and replace couple of standalone libraries in the app our company builds, started from <Calendar /> and <DatePicker />, yet ran into the same issue.

For <DatePicker /> one could probably live with the issue, but here's different use case, where having next / previous month days disabled / hidden feels wrong. We have events screen with calendar in the sidebar - having only current month days clickable seems weird. Here's the screen, hope this gives more context for the problem:

[devongovett]

I'm working on this but I have many questions. Maybe some of you can help me determine what the right behavior is.

Basically it gets really weird when you have multiple months visible at a time, because the same date might be displayed twice.

• Would you expect the selection state to show twice like in the above image? Or only on the first one (which is inside its month)?
• When clicking on one of these dates, where should focus go? Is it weird that clicking on the second copy of a date might actually send keyboard focus to the first one?
• If this was a RangeCalendar, what should we show as the selection state if the selected range spans across multiple months (see below video)? It can look like dates are selected twice, or that there are breaks in the selected range. Would we should the same dates selected twice? Only one of them?

RangeCalendar.mov

• Even with a single month, the range selection behavior is really weird (see below video). As you hover over days, we focus the cell so that keyboard and mouse input can be used together, but for cells outside the month this causes the month to change (as discussed above for keyboard navigation).

Screen.Recording.2023-06-19.at.5.15.08.PM.mov

Any thoughts on the above issues would be appreciated.