Use HTML5 Date Element in the OPAC

[Jason Stephenson]

Following up on this comment:

https://bugs.launchpad.net/evergreen/+bug/1189989/comments/18

I propose replacing the text input boxes used in the OPAC to set dates for hold suspension with the HTML5 Date Element. Doing so would free us from requiring that the date be entered in a specific, US-centric format. The patron/user would be able to enter the date in their native format and/or pick the date from a calendar widget. We would get a standard YYYY-MM-DD format when the data is posted. This can simplify many things, including allowing date validation on the back end.

[Jason Stephenson (jstephenson)]

Branch is user/dyrcona/lp1723651-html5-date-input-in-opac in the working repository.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1723651-html5-date-input-in-opac

I think it's ready to go.

Note that Firefox < 57.0 does not support the HTML5 date input and Safari may not either. I did not add any user agent checking because we don't do that anywhere else in the OPAC as far as I can tell. If anyone thinks that should be done, we could add it and display a message about how to format the date in the text field.

[Kathy Lussier (klussier)]

I like it! What I most like about relying on the date input format is that the calendar widget changes depending on whether your are using a mobile or desktop browser. It means we don't have to worry about optimizing it for the different devices.

For some reason, I had thought Safari supported the date input format, but it must have been a dream. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date says the date input format "is recognized but there is no UI" I'm not sure what 'recognizing' the date input format means.

When I was using the html5 required attribute for parts selection a while back, I added the javascript fallback because Safari, and a couple of other browsers, did not support it at the time. I think we should provide some kind of fallback here if we can because I think we'll inevitably see users who use the unsupported browser.

We could use user agent testing, but would it be better to implement something like what's described in https://quirksmode.org/html5/inputs/tests/inputs_js.html so that we can provide something for users who are using older browsers or the xul client?

[Jason Stephenson (jstephenson)]

There is already a check in the opac/parts/place_hold.tt2 template to check for the XUL client. If that is detected, then the text hint to enter the date in mm/dd/yyyy format is printed.

I think it would be better to check date element support with JavaScript as described in the quirksmode.org link that Kathy shared.

Depending on what is meant by "fallback," I can see 3 possibilities:

1. If the JavaScript determines that the date element is not supported, then add some JavaScript to write out the hint on how to enter the date.

2. If the JavaScript determines that the date element is not supported, then use a jQuery Datepicker.

3. Switch from the HTML5 date element to the jQuery Datepicker in all cases.

Of these, Number 1 is the easiest. Number 2 is the most complicated. Number 3 makes more sense to me than number 2, because why have different date pickers?

If anyone else sees any other options, please, chime in.

[Kathy Lussier (klussier)]

I prefer #1.

[Jason Stephenson (jstephenson)]

I have rebased my branch on master and added a commit to do #1 from comment #3. I stole the function from quirksmode.org to check if a browser supports a particular element.

The only browsers that I have tested so far support the HTML5 date element, so if someone could test it in a browser that doesn't, it would be most useful.

[Kathy Lussier (klussier)]

I asked somebody to test this in Safari earlier this week. Unfortunately, the hint did not display for them. There was just a text entry box in the form.

[Jason Stephenson (jstephenson)]

Wish that I had a decent way to test with Safari, but I don't.

If Safari is a deal breaker, then I think our only option is to go with a non-standard date picker, such as https://eonasdan.github.io/bootstrap-datetimepicker/ or something from JQuery.

[Garry Collum (gcollum)]

It looks like the hint isn't displaying in Safari because it can't find the supportsType function (This error is also displays in the console in Firefox and Chrome).

As a test, I copied and pasted this function from js.tt2 into <head> and the hint displayed. See the attached image. But it does look like the function needs to be tweaked to be a little more date-centric. 'mm/dd/yyyy' instead of 'Hello World.'

[Jason Stephenson (jstephenson)]

This one should have had the pullrequest tag removed, but other things got in the way. I'm not actively working on this but may return to it at some point.

[Jason Stephenson (jstephenson)]

For reference, here's the Webkit bug on input type date not working in Safari on Mac OS X: https://bugs.webkit.org/show_bug.cgi?id=119175

[Jason Stephenson (jstephenson)]

Looks like the Safari bug was fixed in 2020: https://bugs.webkit.org/show_bug.cgi?id=119175#c20

Perhaps it is time to dust off this old bug and see about implementing it?

[Stephanie Leary (stephanieleary)]

Adding a cross reference to bug 1774253 where the date of birth field is also under discussion.