https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42403 Bug ID: 42403 Summary: We should drop Flatpickr in preference for native datepickers Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@openfifth.co.uk QA Contact: testopia@bugs.koha-community.org CC: blawlor@clamsnet.org, daniel.jones@cheshiresharedservices.gov.uk, david@davidnind.com, dcook@prosentient.com.au, fiona.borthwick@openfifth.co.uk, gmcharlt@gmail.com, kyle@bywatersolutions.com, lucas@bywatersolutions.com, martin.renvoize@openfifth.co.uk, matt.blenkinsop@openfifth.co.uk, oleonard@myacpl.org, sally.healey@cheshiresharedservices.gov.uk, testopia@bugs.koha-community.org Depends on: 33886 Blocks: 23003 Flatpickr doesn't seem to go down well in accessibility circles and we keep getting general complaints about it.. at the same time native date inputs have really come on in recent years... It's time to rethink our datepicking.. with that in mind I did the following review. Here's my analysis of what flatpickr provides and what we'd lose. 1. What native HTML inputs CAN replace (covers ~80% of uses) =========================================================== * Date/Time/Combined pickers: Use native type="date", "time", or "datetime-local". * Constraints: Use "min" and "max" attributes. * Masking: Not needed; native inputs handle format natively. * Date format: Uses browser locale (better for a11y). * JS Logic: Simple tasks like "set-to-today" use trivial valueAsDate JS. 2. What needs custom JS but is straightforward (~10%) =========================================================== Feature | Replacement ----------------------------------|-------------------------------------------- Date range linking (data-date_to) | ~20 lines vanilla JS 'change' listener fp_incr() calls | Native new Date(d.setDate(...)) flatpickr.parseDate() | Native new Date() + format-aware parsing .setDate() / .selectedDates | Direct .value / .valueAsDate access ._flatpickr instance access | Direct DOM .value access Validation (validate_date) | Native 'invalid' event for custom messages 3. What we'd genuinely LOSE (~10%, but the hard 10%) =========================================================== * Arbitrary date enable/disable: Native inputs only support contiguous ranges. This is a dealbreaker for: - Bookings module (disabling dates based on availability). - Future-inclusive editing (selecting original past date OR future dates). - Holidays module (marking specific closed dates). * Shortcut buttons: No native equivalent for Yesterday/Today/Tomorrow buttons. * Period/range selection: Native inputs don't support range-in-a-single-field; would require two inputs. * Vue wrappers: Need new components for ERM/Acquisitions. * Format consistency: Native follows browser locale, not the Koha 'dateformat' system preference. 4. Verdict =========================================================== Flatpickr could be removed for the majority of inputs (filters, patron forms, etc.). However, it cannot be removed from the Bookings or Holidays modules without a replacement widget that supports disabling arbitrary dates. Proposed Path: 1. Phase 1: Replace simple inputs with native. 2. Phase 2: Build thin abstraction for range linking. 3. Phase 3: Keep Flatpickr for complex views or evaluate an accessible alternative. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23003 [Bug 23003] [OMNIBUS] Accessibility improvements https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33886 [Bug 33886] Flatpickr calendar - year controls for date of birth on memberentry.pl are not intuitive -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.