Support new html5 input types in read-form

[jacobemcken]

I have only tested read-form on the type "number", "tel" and "email" in html5:
http://dev.w3.org/html5/markup/input.html

"tel" and "email" failed but I guess that my browser identifies type="number" as text (at least something known) because that seems to work even tough it isn't defined as a type here:
https://github.com/ckirkendall/enfocus/blob/master/src/cljs/enfocus/core.cljs#L527

[ckirkendall]

Thanks I will do some testing and see if we can't extend it to all html5 input types.

[jacobemcken]

I might have some time over the weekend to make a patch for it if you would like that?

[ckirkendall]

That would be awesome! Thank you!

[jacobemcken]

I'm still on it (didn't have as much time as expected), I'll let you know if I give up.

[jacobemcken]

I'm still working on it :)
But I thought you might have some comments on the stuff so far?
https://github.com/jacobemcken/enfocus/commits/master

[ckirkendall]

Love the re-factoring and the break out for number and date are looking really good.

[jacobemcken]

I'm currently challenged by how the browsers have implementing datetime and datetime-local.

Provided that the following date has been selected: 2013-12-08 12:00:00
Extracting the value via the DOM gives the following in Opera (which along with Safari is the only browser currently handling both widgets):

datetime (UTC): 2013-12-08T12:00Z
datetime-local (local timezone): 2013-12-08T12:00

This seem align perfectly with the HTML5 spec for form input

The problem is that parsing these strings along to the Date object constructor gives different results in the different browsers.

I have tested a few browsers using Browserstack:

Internet Explorer 10:

UTC:            Sun Dec 8 07:00:00 EST 2013 
local timezone: Sun Dec 8 12:00:00 EST 2013

Internet Explorer 11:

UTC:            Sun Dec 08 2013 07:00:00 GMT-0500 (Eastern Standard Time)
local timezone: Sun Dec 08 2013 12:00:00 GMT-0500 (Eastern Standard Time)

Safari 6.0

UTC:            Sun Dec 08 2013 13:00:00 GMT+0100 (CET)
local timezone: Sun Dec 08 2013 13:00:00 GMT+0100 (CET)

Firefox

UTC:            Sun Dec 08 2013 07:00:00 GMT-0500 (Eastern Standard Time)
local timezone: Sun Dec 08 2013 12:00:00 GMT-0500 (Eastern Standard Time)

Opera 17

UTC:            Sun Dec 08 2013 07:00:00 GMT-0500 (Eastern Standard Time)
local timezone: Sun Dec 08 2013 07:00:00 GMT-0500 (Eastern Standard Time)

Chrome 31

UTC:            Sun Dec 08 2013 07:00:00 GMT-0500 (Eastern Standard Time)
local timezone: Sun Dec 08 2013 07:00:00 GMT-0500 (Eastern Standard Time)

So IE and Firefox seems to get it right by parsing the strings differently (one for UTC and one for the local time zone). I think implementing something browser specific is out of the question.
But should I just ignore this issue and return "wrong" date objects or drop implementing the date reader altogether and just return the value as a string?

[ckirkendall]

Oh the joy's of bleading edge. :) It might be best to port the following javascript function for the parsing: https://github.com/csnover/js-iso8601/blob/master/iso8601.js

CK

[jacobemcken]

Indeed :)

I will give porting that function a try soonish.

For future reference (mostly for myself) a link containing the Date specification: http://www.ecma-international.org/ecma-262/5.1/#sec-15.9