-
Notifications
You must be signed in to change notification settings - Fork 715
[selectors-4] Issue 11: Introduce pseudo-class matching when user changed the value of an input #1533
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@SebastianZ Could you give some specific use cases, other than those covered by |
Oooh what a fun idea! Here's a quick demo of what using input[--modified] {
background: lime;
} It's kind of fun, and does fill a current gap with |
Given the above linked dirty value, IMHO the best name for this pseudo-class would be The HTML Live Standard defines the dirty flag as
while
In this case dirtiness should bubble up from the |
This would be really useful for creating Material-style inputs that move the label of the input above it. Most implementations I've seen either use JavaScript or take advantage of the |
👍 for :dirty (aka different from what has been submitted by the http response) |
... and :modified would NOT be the same. Modified could mean the same as unix "touched" which could mean the value would be the same but you touched it. |
As there was a lot of positive feedback and possible use cases mentioned, I set this as Agenda+. Sebastian |
With |
There are cases when you want to mark/highlight the input fields that were modified since page load. While this is easy to do for checkboxes/radio buttons (e.g. In the context of |
Wouldn't this be equivalent to |
Would you like to shortly explain how this would work? |
https://drafts.csswg.org/selectors-4/#user-pseudos says:
So |
Thanks! On a quick read I failed to see that You are right that https://drafts.csswg.org/selectors-4/#user-pseudos also says:
<form>
<label>
Volume:
<input name='vol' type=number min=0 max=10 value=11>
</label>
...
</form> Basically the This being said, there probably is a combination of |
The CSS Working Group just discussed The full IRC log of that discussion<emilio> topic: [selectors-4] Issue 11: Introduce pseudo-class matching when user changed the value of an input<emilio> github: https://github.com//issues/1533 <fantasai> emilio: I think this would mostly be an alias to a simple :is(:user-valid, :user-invalid) <fantasai> emilio: but maybe best to have this conversation with Sebastien <fantasai> fantasai: Comment pointing out a few cases where it's not exactly the same <emilio> fantasai: It's not exactly what emilio is suggesting, see last comments in the issue <emilio> bramus: so this is to target inputs, proposed aliases :dirty / :changed / :user-edited <emilio> ... concept is when a user interacts with the input then it would become dirty <emilio> fantasai: the other thing to note is that `:user-valid` / `:user-invalid` is that they trigger on submission, but this presumably won't <tantek> I feel like this has come up in the past but I can't recall what we called it. <argyle> https://angular.io/guide/form-validation#control-status-css-classes <emilio> astearns: should we resolve to work on this? <emilio> bramus: there seems to be a minor difference between :dirty and whether the user touched it <tantek> q+ <emilio> ... e.g., focusing the input would be touched, changing the value would be dirty <emilio> q- <astearns> ack tantek <emilio> tantek: in general looks like a good area to explore <fantasai> tantek: This in general sounds like a good area to explore <emilio> ... I think we have talked about in the past about this but I can't recall where <emilio> ... one question is what happens with autofill and similar interactions <argyle> i found these very helpful in the past: https://www.irccloud.com/pastebin/mBDWfxFT/ <emilio> ... does autofilling + clearing it out get special treatment? <emilio> ... there's a bunch of questions about what other states do we need to design for <emilio> ... we might want to do some more research on that <bramus> Good suggestion <emilio> +1, it seems there's a variety of different use cases that don't quite always match <flackr> q+ <astearns> ack flackr <emilio> flackr: I thought the autofilled text isn't exposed till the user interacts with the field <tantek> I would also advise coordinating this exploration with #openui <emilio> flackr: which would suggest that naively that before you interact with the page it wouldn't be dirty <fantasai> emilio: You're right we dont' expose it <fantasai> emilio: but we do match ?? pseudo-class <dbaron> some of this may differ between password management autofill and more general autofill, too <emilio> s/??/:autofill <tantek> +1 dbaron <emilio> astearns: I'll raise an issue with openui so that they're aware <emilio> ... but it seems we have more questions than decissions at this point <emilio> ... so I wonder if we should take it to the issue again for now <emilio> ... does that sound ok? <emilio> [silence] |
I'm really not a fan of the name |
seems like this would be useful information to expose beyond just through styles. i'd be concerned if a page exposed a bunch of visually changed fields that indicated "these fields have changed", but there is no programmatic exposure of such for people who can't perceive the style changes. Existing pseudo-class styling like |
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 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 Sebastian |
So wanted to add my 2 cents: I just ran into a scenario where I have a FACE web component (Form Associated Custom Element) that is :host(:invalid:user-interacted) {
border-color: red;
} Btw, I am more familiar with the term |
There are probably many people out there that understand the concept of Sebastian |
Isn't this usecase already covered by :user-invalid? And it's twin, :user-valid. |
@jensimmons Yes, the more I read about it, the more I think |
What some in this issue seem to argue for is rather the :blank selector. To create the Material style inputs with labels that are first positioned inside the input but then animate away, what you’re interested in is if the input is blank or not. If the default value is non-empty you also want to move the label. Developers currently need to use :placeholder-shown in combination with a placeholder attribute with whitespace , which is not intuitive and is one of the few remaining reasons why we need JS for our inputs |
if a form attempts to be submitted but a user hasn't filled out required fields, then i don't see why that wouldn't be considered user-invalid. They did not meet all requirements for form submission. |
We need both |
Angular defines the following:
These terms also appear in popular libraries such as React Hook Form, see its These all seems like reasonable pseudos to add to CSS. Regarding the relation to
Also note that an input can be both |
If user-invalid has suboptimal behavior we should fix that, imo |
I'm trying here: Haven't filed one for Firefox Having native CSS selectors for controls states would allow better flexibility though, as you can see Chromium guy who implemented it argues that current behavior is correct and in accordance with the specs. Current behavior is unacceptable per our design guidelines, which is the same as how Angular does it — show invalid controls after user visited them, not edited them. |
That is true. But the html spec could be changed with agreement from vendors and tests.
That's how Firefox used to do it iirc, before I changed it to follow the current spec. |
The current spec only says 3 things:
I believe focusing and leaving an empty required input is exactly "appropriate for highlighting an error to the user" 🙂 I would even go as far as to say focusing and leaving any invalid input should highlight it for user, but I can see how this could be up for a debate so it would be great if we could personalize this to our liking with new selectors. |
Back in 2014 it was suggested to add a pseudo-class matching when a user changed the value of an element. This topic was also already discussed earlier by the CSSWG.
I want to pick up that discussion again. The idea previously was to check whether the current value differs from the default value, expressed in JavaScript syntax, where
el.value !== el.defaultValue
,el.checked !== el.defaultChecked
, currently selected options different from default selected options, etc., depending on the type of input.Suggested names so far are
:changed
,:edited
,:dirty
,:user-dirtied
and:user-interacted
.This would make
:user-invalid
redundant, as it could be expressed by:changed:invalid
.Sebastian
The text was updated successfully, but these errors were encountered: