Comment 2 for bug 1723651

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?