- From: Sebastian Zartner via GitHub <sysbot+gh@w3.org>
- Date: Fri, 10 Nov 2023 08:37:53 +0000
- To: public-css-archive@w3.org
UX is key here and it looks like browsers have different approaches to this. Here's a simple test case similar to @argyleink's one: https://jsfiddle.net/SebastianZ/6mrojuet/ They differ when the value is valid, you blur, then focus again and make the value invalid again. In that case, Chrome matches `:invalid`, `:user-invalid` while Firefox matches `:invalid`, `:user-valid`. So Firefox tries to be smart and resets the behavior back to the initial one in case the value gets invalidated when the user focuses the field again. Though when it's the other way round, i.e. the value is _invalid_, you focus the field again and enter a valid value, `:user-valid` matches immediately. (Maybe someone can provide the behavior in Safari to see whether it behaves differently.) From the user's perspective, I believe Firefox' behavior makes sense. It should be clarified whether there are use cases in which authors need control over that behavior. And regarding debouncing, I want to point out that some users type slower than others. So people might then get a different UX depending on their writing speed. I don't believe that's something desirable. ----- That aside, if we decide that authors should get more control over that, one way to address this would be adding `:valid()` and `:invalid()` pseudo-class functions which take a parameter defining the behavior, e.g. `dirty`, `touched`, and `pristine` as @argyleink mentioned. In that case, we should then also think about extending the Validation API so that Web Components can make use of that as well. Sebastian -- GitHub Notification of comment by SebastianZ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9583#issuecomment-1805311452 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 10 November 2023 08:37:55 UTC