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.
> 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.
(: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.)
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.
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.)
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.
Looking forward to broad support for :has() ... infinite number of good potential use cases. The grid layout example is probably the most interesting here, though the syntax will certainly also make forms more flexible with less structural complexity.
That said, personally I put a bit of effort into achieving (dynamic) ends without javascript (despite being a js dev) and find form styling, with it's intrinsic state, one of the less-problematic things to style. In fact, I tend to use input elements in a bunch of unconventional places as state machines in place of js. Hamburger menus, overlays (prior to the <dialog> tag), dark mode toggle, etc. have all been prime candidates for "previous-sibling" (or "parent-previous-sibling") input treatment.
In the form examples provided, the <labels> being styled could easily be included "after" the <input> in code (regardless of where they appear visually) allowing them to be targeted based on state/focus of the input. Similarly the :focus-within vs :has(:focus-visible) consideration is interesting, but in reality not really a massive concern and certainly not a blocker. The fact that people have relied on JS for this stuff traditionally I think is the bigger concern for me. Here's to progress!
P.S. I mainly like the idea of low/no js from an academic perspective. But I do think it comes in handy in surprising situations, both when a random no-js purist stumbles across your site and is able to do something, but also when something breaks (naughty browser plugin, broken script, dodgy refactor) and people are still able to open your nav / close your popover / fill in your complaints form.
Am I the only one who giggles inside every time I see one of those 100s of named CSS colors being used? They have such cute names some of them. Anitquewhite, dodgerblue (boo!!), darkolivegreen, bloodstainred.
I enjoy using the CSS named colors for web design because it provides a limited set of options to choose from. It's easier to decide on the best choice from a limited set of options than it is to find the global maximum in the entire RGB space.
I'll also forever have a fondness for "cornflower blue" because it was the default fill color when you created a new C# Xbox 360 game using Microsoft XNA.
They're still working out some kinks. Also, the other browsers may have launched a little too early while some weird spec corner cases were getting worked out.
> NOTE: it looks like it's not ordinarily working even when switched on.
I find the :has() selector very useful in certain cases, but firefox doesn't support it yet and like you said, it doesn't work very well even when enabled. What I have done for Firefox is use the `@supports selector` query [1] and fallback to some equally functional but not as nicely styled UI with the hope that when Firefox supports it, it will automatically provide the nicer UI.
Yes, and thinking, that @supports selector is also suggested in one of the examples in the article:
/* Warning message
about support for :has() */
@supports selector(:has(img)) {
body small {
display: none;
}
}
And I sure love it when CSS performs according my preference, but I'd never complain about a UA not implementing or a user prefer her own style over agent or author.
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.