14890 2011-11-20 21:14:02 +0000 For invalid Date, the terminology here seems to be "undefined" insted of "null" according to WebIDL, and the ECMAScript "null" value should never reach here according to the IDL description of attribute "valueAsDate". For readiblity, I suggest we just s/i 2012-07-18 18:47:49 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#dom-input-valueasdate P3 normal Unsorted 1 contributor ian ian kennyluck mike contributor oldest_to_newest 60261 0 contributor 2011-11-20 21:14:02 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html Multipage: http://www.whatwg.org/C#dom-input-valueasdate Complete: http://www.whatwg.org/c#dom-input-valueasdate Comment: For invalid Date, the terminology here seems to be "undefined" insted of "null" according to WebIDL, and the ECMAScript "null" value should never reach here according to the IDL description of attribute "valueAsDate". For readiblity, I suggest we just s/if the new value is null/if the new value is the invalid Date/. Posted from: 114.43.114.197 by kennyluck@csail.mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20100101 Firefox/8.0 61180 1 ian 2011-12-07 23:42:27 +0000 Come again? 61338 2 ian 2011-12-09 22:20:29 +0000 I think the problem here was just that valueAsDate wasn't marked as nullable, but I'm not sure. 61590 3 kennyluck 2011-12-15 05:16:36 +0000 Apparently my one-liner did't work so let me try again. The main problem is as follows. What should happen if the following script is run? var input = document.createElement('input'); input.type = "date"; input.value = "2011-12-15"; input.valueAsDate = new Date("hixie"); // invalid date alert(input.value); This doesn't seem to be well-defined as various "algorithm to convert a Date object to a string" algorithms seem to miss this case (the 'undefined' Date). For your data, Safari 5.1.1 treats invalid date as if it were null and the result is the empty string. Others pretty much don't have implementations close to this nit. (In reply to comment #2) > I think the problem here was just that valueAsDate wasn't marked as nullable, > but I'm not sure. I am not sure why null is better than an invalid date (new Date(NaN)), which I originally thought to be a better idea, but I can agree that null is more testable. (In reply to comment #1) > Come again? I don't understand. Could you elaborate? 63121 4 ian 2012-01-25 23:20:06 +0000 (new Date("bogus")) is exactly equivalent to (new Date(NaN)). It's true that the spec didn't define how valueAsDate should handle a Date with a NaN time value. I have now fixed that. Thanks for the bug report! 63122 5 contributor 2012-01-25 23:20:42 +0000 Checked in as WHATWG revision r6918. Check-in comment: Define how valueAsDate's setter should handle a NaN time value. http://html5.org/tools/web-apps-tracker?from=6917&to=6918