I've been working on PHPMailer-FVE for some time now. I came across an issue others should be aware of.
Background: I am an advocate on using every possible security technique in dealing with forms and emails. In forms, I use front-end strategies and back-end strategies. Front-end usually means HTML5 and/or Javascript. Personally, I think HTML5 is suitable as a front-end strategy. I used to use Javascript (even had my own Javascript library, but gave up on that). I combine HTML5 with JQuery Mask to influence user input. PHPMailer-FVE is the back-end strategy. Anything that slips by HTML5 and/or JQuery Mask gets nailed by PHPMailer-FVE.
I ran into problems on the front-end side with the input date type. HTML5 has a nice feature that displays a small calendar in the input field. Click on the calendar icon, and a selector pops up letting the user select the date. The problem I have run into, and most others will at some point, is that the display in the input field is based on the user's OS short-date settings. Any tips or instructions on filling in the date field will be invariably wrong based on what gets displayed to some of the users. Unpredictable – and that's the last thing you want as a UI element.
I need to separate processing from display. In terms of processing, the date field is always in YYYY-MM-DD format. So, programmatically you can always depend on that format. What we are talking about is display ... how the date displays for the user in the date input field. In typical cases, the input date field will display as MM/DD/YYYY. It could, in some cases, also display as DD/MM/YYYY. If the user has some other preference and sets that in the OS settings (as short-date), the display becomes completely unreliable.
There's another issue, slight, but still an issue. When you have an input type date field, the only way of getting the calendar to pop up is to press the calendar icon at the far right of the input date field. I'd personally like the calendar to pop on entry into the field by tab or click. It doesn't do that in plain HTML5.
So, back to drawing board and create a Javascript solution. Rather than re-invent the wheel, I decided to use a pre-built library. Nothing large, a simple calendar object will do. One where the date format for display purposes can be modified. One where the calendar object pops up on entry into the field (by mouse or keyboard).
I found that in Zebra Calendar – with a bonus, no need for JQuery UI. The minified javascript library plus the css file plus the icon (png) file is a grand total of 40kb.
Configuration was simple, I only needed two settings: the first to display the calendar object with the first day of week as Sunday, the second to display dates in "MM/DD/YYYY" format.
I then found the library which I now use exclusively. It's Pikaday and has no dependencies. It's vanilla Javascript (does not need JQuery). At first, I was going to pass on it, the configuration was a bit daunting. However, once I got it to work the way I wanted it to, I modified the script and then minified it to the version I now use. The total of the minified Javascript file and the minified CSS file is 21 Kb. There are no icons needed, the calendar selector object pops up on entry of the input field via keyboard or mouse.
The modifications I did to the script narrow its use to quite a specific need. That is, the input field display is always in MM/DD/YYYY. And, note, this does not affect the processing format (remains the default: YYYY-MM-DD).
It's a simple solution. And now all forms with a date field are left intact with the type="text" and display controlled by the Pikaday script. I can use JQuery Mask to control user input strings and PHPMailer-FVE to validate the data.