Manuel Strehl

Possible fix: Everywhere, where we compare some `element` with some `window` property, use ``` function w(element) { return element.ownerDocument && element.ownerDocument.defaultView || window; } // and then w(element).HTMLFormElement ```

Sorry for the delay! Yes, using AJAX for validation is a bit tricky. Theoretically, one could use _synchronous_ requests to block form submission until all validation is done, but that...

Yes, the `current_request.abort()` is not, what you really need to do to abort a `fetch` request. I’ve added a link to how the real code would look in the comment...

Yes, agreed. I’ve also already played with such an idea in the context of externally provided translations. The most important part is to get the signature of the callback function...

That's indeed a problem with browsers, that _do_ support `type="number"`. Thanks for reporting! The actual problem is, that the browser's UI is intercepting the user's input before it reaches the...

Yes, _that_ is actually the only thing that the browser let's trickle down to the DOM, that there was an error (specifically a “bad input error”).

Thanks for the report! Actually, there are two things going on here. It’s no oversight, that `text` is missing from the list you quote, because a plain `text` input can...

Could you test the new v0.9.21 in your setup, please? I’ve worked in exactly that area (`validity.badInput` wasn’t found in some instance), and the problem might be fixed now.

Thank you for the report! Unfortunately, with my Firefox 60 on Linux and a Browserstack Firefox 60 beta on Win10 I can’t reproduce your test case (verbatim copied for Linux,...

Locale is a good point! I’ll try to reproduce the error with another set-up, but that might take some time (currently much to do getting EU GDPR requirements set up).