- From: Sebastian Zartner via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Jul 2022 19:20:36 +0000
- To: public-css-archive@w3.org
Sorry that I missed the call! Good points were brought up there! So it obviously needs to be precisely defined what actions cause this pseudo-class to match. As stated in my initial comment, as a user I'd expect it to match whenever I interacted with the form control and changed the value it had when the page loaded. I am leaning towards counting autofill to that, as long as the user has chosen the autofill option. Also, we need to consider how this works in context of single-page applications. In that regard, is the state reset - i.e. the pseudo-class does _not_ match (anymore) - when the value is changed programmatically? I'd say yes. That's also a reason why `:is(:user-valid, :user-invalid)` isn't sufficient. One more question is, what should happen if the user changes the value back to the value that was initially set? I'm unsure about that but I tend to think that the pseudo-class should not match anymore in that case. Regarding the name, I prefer one that makes it clear that there was some user interaction. This could simply be `:user-changed`, or `:edited`. Therefore, I'd exclude `:changed` as that sounds like user interaction isn't necessary, `:dirty` because of the reasons @jensimmons mentioned, `:user-dirtied` for the same reasons, and `:user-interacted` because "interacted" doesn't mean changed. Sebastian -- GitHub Notification of comment by SebastianZ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1533#issuecomment-1184810731 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 14 July 2022 19:20:38 UTC