Not quite, right? When the user blurs out of the field and it's marked as invalid, when the focus goes back to the input, we'd probably want to keep the field marked as invalid.
Personally I would be aiming for consistency / simplicity. There's so many good ways to solve this at a design level without introducing a multi-phased state system. But that's me.
But that's the thing: many JavaScript form validation libraries already do implement the state machine and present a consistent and simple API for the developer to use. It would be nice if this built-in stuff could fully replace JavaScript form validation libraries, but it's just not there yet.
Totally get that. And I think if those are the conventions you're designing form interactivity with then, absolutely, you probably need a javascript library to validate and step your user through form submission.
My point is that this should be the exception, not the rule. I certainly don't think this level of abstracted complexity is necessary, or even better, in most scenarios. I'm talking at a design or implementation level.
Many people are significantly less technically savvy than you might expect. Every form really needs all of these conventions if you want to make your software as widely usable as possible (which is all consumer software at least, or should be).
So in fact I think it is the rule, not the exception.
Unfortunately you have to do a dumb JS dance to get these reasonable affordances. Hard to blame people for not reimplementing all this shit even if it’s critically useful for many folks.
