Open silverwind opened 1 year ago
This is a good idea. Additionally I think we can afford to start with a console.warn
and then throw a RangeError for a breaking release. Down with non-iso8601 dates!
If we validate for the specced Date Time String Format, which every JS engine is guaranteed to support, it would be ideal. It should be a pretty trivial regex.
As for errors, I would prefer something that can be caught in window.onerror, console logging is easier to miss, but it might serve as a start to help people migrate to the proper format.
I concur but an error would be a breaking change. I’d like for our breaking changes to have a lead up so IMO a console warn should happen in a minor first.
The docs about the
datetime
attribute say:This statement is incorrect. Any value that can be passed to the
Date
constructor will work which presents a cross-browser issue because JS engines are inconsistent in which formats theirDate
constructor accept.For example, the golang default string representation only parses in v8:
Also try this fiddle in multiple browsers.
How about adding an option attribute to pass in a validation regex into the element to validate the passed dates, when present? This would at least not make this issue missable by developers who only test in Chrome.