enfocus icon indicating copy to clipboard operation
enfocus copied to clipboard

Published 20 hours ago • verified publisher icon ckirkendall

Support new html5 input types in read-form

Open jacobemcken opened this issue 11 years ago • 9 comments

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

jacobemcken avatar Nov 21 '13 14:11 jacobemcken

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

ckirkendall avatar Nov 21 '13 21:11 ckirkendall

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

jacobemcken avatar Nov 22 '13 06:11 jacobemcken

That would be awesome! Thank you!

ckirkendall avatar Nov 23 '13 17:11 ckirkendall

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

jacobemcken avatar Nov 25 '13 08:11 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

jacobemcken avatar Dec 07 '13 15:12 jacobemcken

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

ckirkendall avatar Dec 07 '13 15:12 ckirkendall

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?

jacobemcken avatar Dec 09 '13 07:12 jacobemcken

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

ckirkendall avatar Dec 09 '13 13:12 ckirkendall

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

jacobemcken avatar Dec 10 '13 14:12 jacobemcken