verbb / formie

The most user-friendly forms plugin for Craft CMS.
Other
93 stars 70 forks source link

Native HTML date field #1713

Open MoritzLost opened 5 months ago

MoritzLost commented 5 months ago

What are you trying to do?

There are three options available for date fields: Calendar, Dropdowns and Text Inputs. The latter two provide individual fields for year, month date, and time, which is not great in terms of UX. The calendar option displays a JS-powered calendar picker, which is a bit difficult to use on mobile. It's also inaccessible – for example, the calendar is completely inaccessible to keyboard navigation.

What I'm missing are the native HTML inputs of type date or datetime-local. While those aren't perfect, they generally provide superior UX and accessibility, since every browser/operating system can provide their own optimized interface.

What's your proposed solution?

Add an option to date fields to output the field as a native input of type date or datetime-local (depending on whether the field includes a time).

Additional context

No response

engram-design commented 5 months ago

There's technically 4 types, because the Flatpickr date picker is optional. It provides a lot more functionality than the native HTML elements. To use the native inputs, ensure you set the Calendar and under Appearance, turn off "Use Date Picker".

While I whole-heartily agree that using the native inputs is the way to go for many reasons, I believe we needed to implement it due to lack of support with Safari - at least at the time.

We may even look at providing multiple libraries for the date picker, one that at least provides better accessibility, but it's also an option to steer people to the native controls. In our experience, people do want features like date ranges, a streamlined control, etc.

MoritzLost commented 5 months ago

@engram-design Thanks, I totally missed that!

Is there any way to set this as the default? In Formie -> Settings -> Fields I can only set the Default Date Display Type to Calendar, but not turn off the datepicker by default. Clients like shiny things and the option is pretty easy to miss, but I want to make the defaults as accessible as possible …

While I whole-heartily agree that using the native inputs is the way to go for many reasons, I believe we needed to implement it due to lack of support with https://github.com/verbb/formie/issues/312 - at least at the time.

Yeah I agree, Safari was a bit lacking there. What I did a couple years back was use type=date with a fallback pattern that enforces YYYY-MM-DD format (with usage instructions, of course). Safari falls back to a text input and uses the pattern, so the server gets an ISO8601 date, same as with the native input.

But anyway, support for date inputs is now pretty good, so native date inputs are a reasonable default now.

We may even look at providing multiple libraries for the date picker, one that at least provides better accessibility, but it's also an option to steer people to the native controls. In our experience, people do want features like date ranges, a streamlined control, etc.

Maybe the default can just be changed to a native input at this point? A JS-based datepicker should be opt-in IMO. Date ranges are somewhat niche, and if you need it, you can always turn on the JS datepicker.

Or provide a setting to change the default globally?

engram-design commented 5 months ago

Not quite yet sorry. We're working on adding proper field defaults for this sort of thing. There's only a tiny amount of field defaults in Formie > Settings > Fields.

The only reason it's default is as I mentioned was Safari holding us back, and getting us into trouble with plenty of Safari-loving clients. I believe that's no longer an issue as of the last few Safari versions - as you mentioned.

We'll consider changing the default value for Formie 3 for Craft 5, due to the breaking change after some further testing.

MoritzLost commented 5 months ago

@engram-design +1 for changing the default! Safari 14.1+ support native date inputs, should be enough for most use-cases.