Hacker News Reader

Comment by adregan | Hacker News Reader

These are all handy, but I’ve never met a designer who’s content with the default behavior of input validation and have always been required to smooth out the interactions with JavaScript.

In some cases, I actually agree that the default behavior is rough. For example, type a single character in the email input in the example in the article and notice that the field immediately transitions to the error state even though you’re still typing.

It’s not a friendly experience—at best it’s pedantic—and I’ve never met a designer who hasn’t requested that the error state only be used when the user removes focus from an input. You could perhaps use a sequence of pseudo classes, but in practice, it’s typically much harder to follow that logic in CSS vs JS.

View on HN

> For example, type a single character in the email input in the example in the article and notice that the field immediately transitions to the error state even though you’re still typing.

The solution for this is :user-invalid. Firefox has had it for a year and a half, WebKit has https://github.com/WebKit/WebKit/pull/5958 hopefully landing soon, Chromium has no activity on https://bugs.chromium.org/p/chromium/issues/detail?id=115606.... For fresh development these days, I would recommend using :user-invalid and polyfilling, rather than implementing your own very similar semantics in your own way in JS.

See https://developer.mozilla.org/en-US/docs/Web/CSS/:user-inval... for a demo.

(:user-invalid as an alternative to :invalid joins the list of presentational nuance pseudoclasses that allow you to match what browsers themselves do in their default styling, joining :focus-visible which is an alternative to :focus.)

> I would recommend using :user-invalid and polyfilling

Is there a polyfill you can recommend?

No idea, sorry. I haven’t had cause to want this sort of thing in the last couple of years (or I’d have done it myself if no one else has). It’s not unlikely, in fact, that no one has actually written a suitable polyfill yet, of similar nature to :focus-visible polyfills. But if one wants to implement such a thing, :focus-visible polyfills are a decent starting place to look at and think about.

Can't you combine with :not(:focus) ? That should trigger the CSS only after the field is left.

Or use a transition to show the error a few seconds later than the input happened.

You want the error to still be there if the user focuses on the input again, though. And you also want to error to appear immediately when the user blurs the input - you don't want them to be three fields ahead when you finally tell them about their first error!

In general I agree that we should be looking for CSS/built-in solutions to these sorts of input state problems, but this is one of those cases where you either use JavaScript, or accept the accessibility hit. (Bearing in mind that JavaScript itself can be an accessibility hit in its own right.)

I don't think it's much harder to follow that logic. You just replace `input:invalid` with `input:invalid:not(:focus)`.

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.

I'll have to respectfully disagree. Not with your first sentence, that's true enough, but everything else.

Reply on news.ycombinator.com