[everdimension]

I totally understand this. Having DOM elements as an entry to some API isn't the best thing.

But firstly, I would consider what you're missing when you abandon native validation

* On submit, the first field that needs attention gets focused automatically

* Error messages for semantic attributes are localized automatically by the browser

* The native message tooltip are actually nice and their placement is handled by the browser. They aren't the best fit for any design system, but for many products they are way nicer than custom implementations.

* Possible styling using CSS pseudo-classes such an ":invalid" or ":user-invalid"

In the end, I do think that the developers would benefit from a more explicitly exposed API for this. Just like we got the "new URL()" constructor, but earlier we had to create an anchor node, fill in its "href" attribute and then read the anchor properties to get to the parts of the parsed URL.

[wvenable]

> On submit, the first field that needs attention gets focused automatically

That is long solved.

> Error messages for semantic attributes are localized automatically by the browser

Assuming I want to use their error messages. I would prefer to provide my own, more detailed, error messages. Also what good is localized error messages in a non-localized form?

> The native message tooltip are actually nice and their placement is handled by the browser.

I definitely don't like the placement of the tooltip nor do I even like using tooltips for showing error messages. I much prefer permanently keeping the error message displayed under the field until the user edits the field.

I make some pretty large forms in my job with a lot of complex validation rules and non-technical users. We do validation way better than this.