New Feature: Date Picker

[TedGoas]

Is your feature request related to a problem? Please describe. Stack Overflow has a few instances of a data picker. The current solutions are all different (jQuery UI) and not very robust.

Describe the solution you'd like A date picker in Stacks that includes:

1. A few predefined ranges.
2. Support for custom date ranges.
3. Theming support (eg. Enterprise, network sites)

Describe alternatives you've considered jQuery

Additional context @UXPiper worked on a few mockups here and here:

[UXPiper-zz]

This is the final design spec: https://stackexchange.invisionapp.com/share/MTP7KOWEZ7R#/332358366_SO-Stacks--v01__Design-Spec__Date-Picker

[dancormier]

PLATENG-734

UPDATE

I linked to a Jira issue and decided to put my notes there. That doesn't make much sense considering this is a Stacks component discussion we're having.

The next few comments are my notes (and some helpful input from @bnickel) ported from the Jira issue.

[dancormier]

From Jira, @dancormier commented 5 days ago:

---

vanillajs-datepicker

A quick search lead me to vanillajs-datepicker, which looks pretty badass* overall.

*badass in this context means accessible, configurable, and full featured.

Size

I did a back-of-the-napkin calculation and found the minified CSS + JS to land around 10-11KB†

†I need to verify this and this may depend on which features we’d like to include in our component.

Features

• Roll your own element classes. This would allow us to apply Stacks atomic classes.
• Includes options for displaying inline or popover.
• Includes option for individual date, range selection, and multi-date selection.

Maintenance

• It’s being actively maintained, albeit with the vast majority of contributions from a single contributor (maybe a small OSS sponsorship candidate).

Potential issues

• Single maintainer.
• Expects an <input type=”text” />. Seems like a type=”date” would make more sense (I assume it’s to avoid fighting with native date pickers).
• Accessibility concerns.
  • Yellow flag: I noticed it uses <span>s for the date items. Feels like that should be <button>s.
  • Keyboard navigation felt pretty intuitive, but not sure it cuts it.
• What’s our bundle size tolerance here?

[dancormier]

From Jira, @dancormier commented 5 days ago:

---

flatpickr

Features

• There’s an actively maintained Stimulus.js wrapper, along with wrappers from other frameworks.
• Turns into a native input on mobile.

Maintenance

• Latest release came in December 2020, but the repo has had many contributions since then.

Potential issues

• Far from headless. UI doesn’t seem to be all that customizable (can’t add custom classes where ever).
• Lots of issues on GitHub.

Investigate

• Size.
• Is there some way we can make this look like Stacks?
• Additional killer features? I haven’t dug hard into this one.

[dancormier]

From Jira, @bnickel commented 5 days ago:

---

For awareness, here’s some places where we use date pickers today and ones with nuance. We generally, but not always, deal with date ranges.

https://stackoverflow.com/admin/community-events

This is the only scenario I know of where time is involved. Also the only one where we display in local timezone.

https://stackoverflow.com/admin/user-activity

https://stackoverflow.com/admin/analytics

https://stackoverflow.com/ads/sponsorships/add

https://stackoverflow.com/cm/elections/add

This one only lets you pick Tuesdays.

https://stackoverflow.com/events/core

This one uses the native date input.

Channels admin

These ones support an unbounded date.

Enterprise

Enterprise has some date pickers and I believe a custom component, but I’ve not looked into those.

---

Then I thanked Brian.

[dancormier]

From Jira, @dancormier commented 3 days ago:

---

<input type="date">

So, yeah we might be better off starting with a good, old fashioned <input type="date">. Seems like it would do the job when it comes to most of the date inputs we already have littered across the site.

If we went this route, we could start with this native input and bring in a different solution when it’s needed. I’d consider this the YAGNI approach.

Handy references

• <input type="date"> - HTML: HyperText Markup Language | MDN
• Date and time input types | Can I use... Support tables for HTML5, CSS3, etc

Features

• It’s a damn native input 🎉 It feels right for your platform and would probably be a good choice when considering Jakob’s law.
• No JS (though we could lightly extend it with JS). You can’t get lighter-weight than this.

Potential issues

• That damn calendar icon is on Chrome, Edge, and Opera. It would need a filter: invert for dark mode.
  • Change color of Chrome's calendar icon in HTML Date Input
  • And no, we shouldn’t just display: none; on it because it’s the only way to trigger the calendar widget.
• Calendar widget is not embeddable in-page
• Date range isn’t the cleanest experience (requires two separate inputs).
• I’ve seen accessibility issues related to date inputs specifically when using voice-based assistive technologies. I’m not sure of the situation there currently, but I’d note that this input is almost certainly more accessible to all js-based date pickers.
  • input(type-date)_element (html) | Accessibility Support
  • Is input type="date" ready for use in accessible websites? - Hassell Inclusion
• While the input supports min and max attributes, they seems to only limit selection on the calendar widget the input provides in some cases. Keyboard input can get around those attributes.
  • Observed in Firefox and Safari. Not an issue in Chrome AFAICT.

[aaronshekey]

Thanks for gathering this info, @dancormier. Seems like we could refactor to native date inputs on the way to something more fully-featured / customizable. Leaning toward Vanilla?

[dancormier]

@aaronshekey yep, leaning vanilla for sure. I think it will meet most of our needs and can be extended if we absolutely need it*. If we're okay with working with a simplified picker to start, vanilla is probably the flavor we want.

*I'm thinking in the case of the one date picker at /cm/elections/add that only allows Tuesdays.

[dancormier]

TL;DR: I advise we implement the date picker without third party libraries and stick with a native <input type="date" />.

Requirements and goals

Based mostly on the existing implementations provided by @bnickel, it seems like our requirements largely overlap from one implementation to another.

Common requirements

Must have

• A input field to type the date
• A calendar interface to select a date
• An accessible interface
• Minimum browser support
• Actively maintained

Nice to have

• Small (or no) JS footprint
• Dark mode support
• Simple localization
• Date range support

One-off requirements

Here are some features implemented in individual existing date pickers on our products:

• Limit date selection to specific day(s) of week
  • See comment on https://stackoverflow.com/cm/elections/add
• Conjoined date + time selection*
  • See comment on https://stackoverflow.com/ads/sponsorships/add

Findings and recommendations

I'd advise replacing current date picker implementations with <input type="date"> in the interum (at least). This way, we can provide the user with a consistent, dependable, lightweight date picker and extend (or replace) it at a later date if the need arises.

---

Clear advantages

Using a native input with no third party libraries has clear advantages over third party implementations:

• Developer and designer effort: Because it's a native input, it'll use the native styling defined by the browser and OS. This will ensure it feels natural to the user (at the cost of not being able to style part such as the calendar).
• Size: Doesn't get much lighter than a single DOM element and a little CSS. We can augment it with JS, but I suspect we'll often be fine with no JS.
• Browser support: It's supported in all browsers we support.
• Maintenance: It's unlikely to be deprecated anytime soon and we'd have a big heads up if it was.

Likely advantages

It seems a native input will excel at:

• Accessibility: I'm confident this will be the most accessible option, but I've read(citation) some critiques of the native input when used in conjunction with VoiceOver.
• Localization: I've had trouble simulating this native input adhering to local date formats, but I suspect it does. I'd love some confirmation.

Disadvantages/compromises

There are a few compromises if we go with a native input:

• Customization/theming: We won't be able to customize the calendar interface and the calendar icon shown in some browsers.
• Selection of arbitrary dates: We could prevent the user from submitting a given date, but we won't be able to disable dates on the calendar picker arbitrarily, like in the current picker at https://stackoverflow.com/cm/elections/add. when it comes to developer/design effort, size, and browser support. It's likely to provide the most accessible interface (though issues have been reported).
• Dark mode: The input can have light/dark styling applied like most other inputs, but the calendar seems to stay white no matter the dark/light context.
• Date range support: The first comment on this issue asks for "support for custom date ranges" and "a few predefined ranges", which this solution cannot provide.
• Conjoined date time picker: See "Including time selection in the date picker" below*

*Including time selection in the date picker

Many third-party JS date pickers include an option add time selection to the date input. If we go the vanilla route, we might be able to get away with the picker just being HTML and CSS. We have a couple options if we go the vanilla route:

Using <input type="datetime-local" />

This could be an input type we support and endorse in addition to date. At the time of this writing, it's supported in all browsers Stacks supports except Firefox... BUT, after digging into a 5 year old bug report, it looks like Firefox support is on it's way (as of 2 days ago 😮).

See also Date and time input types | Can I use...

Using separate <input type="date" /> and <input type="time" /> inputs

This is probably the best vanilla option initially. It would allow us to replace existing date and time pickers with a lightweight, well-supported option.