[everdimension]

I think the problem here is not as much with the absence of custom styling, because you can quite easily read the native "validity" state of the input and render it however you want.

The problem is that it's quite tricky to correctly subscribe to the changes of this validity state. There are indeed some validity events being dispatched, but unfortunately not always. Updating form state programmatically (such as calling "form.reset()" or setting input value via "input.value = '...'") doesn't trigger these events.

I think this is a separate good topic for investigations and for suggestions to the web platform

[chii]

I think form validation should remain an app implemented part of a web form, rather than natively built into the browser.

The majority of the work in form validation is not in the validation of the data, but in the UX and interaction, display and update of state. There's no generic way to handle it, as it's very dependent on the app itself.

Keeping the browser smaller and cleaner, with less logic seems to be a better idea.

[DaiPlusPlus]

> Keeping the browser smaller and cleaner, with less logic seems to be a better idea

That idea died sometime around 15 years ago.

Chromium can probably be best-described as a kind-of user-mode OS at this point.

[braiamp]

Checking if a string is a email (or at least looks like one), if it's a number, etc. is such a cheap processing, that setting up and tearing down a connection to the server to process it is a waste of resources. Client side validation has its uses, it's more responsive. The problem is that we want all these custom behaviors when it's actually some rudimentary data input validation.