Re: [csswg-drafts] [selectors-4] Issue 11: Introduce pseudo-class matching when user changed the value of an input (#1533)

The CSS Working Group just discussed `[selectors-4] Issue 11: Introduce pseudo-class matching when user changed the value of an input`.

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> topic: [selectors-4] Issue 11: Introduce pseudo-class matching when user changed the value of an input<br>
&lt;emilio> github: https://github.com/w3c/csswg-drafts/issues/1533<br>
&lt;fantasai> emilio: I think this would mostly be an alias to a simple :is(:user-valid, :user-invalid)<br>
&lt;fantasai> emilio: but maybe best to have this conversation with Sebastien<br>
&lt;fantasai> fantasai: Comment pointing out a few cases where it's not exactly the same<br>
&lt;emilio> fantasai: It's not exactly what emilio is suggesting, see last comments in the issue<br>
&lt;emilio> bramus: so this is to target inputs, proposed aliases :dirty / :changed / :user-edited<br>
&lt;emilio> ... concept is when a user interacts with the input then it would become dirty<br>
&lt;emilio> fantasai: the other thing to note is that `:user-valid` / `:user-invalid` is that they trigger on submission, but this presumably won't<br>
&lt;tantek> I feel like this has come up in the past but I can't recall what we called it.<br>
&lt;argyle> https://angular.io/guide/form-validation#control-status-css-classes<br>
&lt;emilio> astearns: should we resolve to work on this?<br>
&lt;emilio> bramus: there seems to be a minor difference between :dirty and whether the user touched it<br>
&lt;tantek> q+<br>
&lt;emilio> ... e.g., focusing the input would be touched, changing the value would be dirty<br>
&lt;emilio> q-<br>
&lt;astearns> ack tantek<br>
&lt;emilio> tantek: in general looks like a good area to explore<br>
&lt;fantasai> tantek: This in general sounds like a good area to explore<br>
&lt;emilio> ... I think we have talked about in the past about this but I can't recall where<br>
&lt;emilio> ... one question is what happens with autofill and similar interactions<br>
&lt;argyle> i found these very helpful in the past: https://www.irccloud.com/pastebin/mBDWfxFT/<br>
&lt;emilio> ... does autofilling + clearing it out get special treatment?<br>
&lt;emilio> ... there's a bunch of questions about what other states do we need to design for<br>
&lt;emilio> ... we might want to do some more research on that<br>
&lt;bramus> Good suggestion<br>
&lt;emilio> +1, it seems there's a variety of different use cases that don't quite always match<br>
&lt;flackr> q+<br>
&lt;astearns> ack flackr<br>
&lt;emilio> flackr: I thought the autofilled text isn't exposed till the user interacts with the field<br>
&lt;tantek> I would also advise coordinating this exploration with #openui<br>
&lt;emilio> flackr: which would suggest that naively that before you interact with the page it wouldn't be dirty<br>
&lt;fantasai> emilio: You're right we dont' expose it<br>
&lt;fantasai> emilio: but we do match ?? pseudo-class<br>
&lt;dbaron> some of this may differ between password management autofill and more general autofill, too<br>
&lt;emilio> s/??/:autofill<br>
&lt;tantek> +1 dbaron<br>
&lt;emilio> astearns: I'll raise an issue with openui so that they're aware<br>
&lt;emilio> ... but it seems we have more questions than decissions at this point<br>
&lt;emilio> ... so I wonder if we should take it to the issue again for now<br>
&lt;emilio> ... does that sound ok?<br>
&lt;emilio> [silence]<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1533#issuecomment-1183431862 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 13 July 2022 16:27:20 UTC