github / relative-time-element

Web component extensions to the standard <time> element.
https://github.github.io/relative-time-element/examples/
MIT License
3.57k stars 170 forks source link

Stricter `datetime` validation #266

Open silverwind opened 1 year ago

silverwind commented 1 year ago

The docs about the datetime attribute say:

This must be a valid ISO8601 DateTime

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 their Date constructor accept.

For example, the golang default string representation only parses in v8:

$ eshost -e "new Date('2009-11-10 23:00:00+00:00 UTC')"
#### JavaScriptCore
Invalid Date

#### spidermonkey
Invalid Date

#### v8
Wed Nov 11 2009 00:00:00 GMT+0100 (Central European Standard Time)

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.

keithamus commented 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!

silverwind commented 1 year ago

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.

silverwind commented 1 year ago

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.

keithamus commented 1 year ago

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.