[selectors-4] Issue 11: Introduce pseudo-class matching when user changed the value of an input

[SebastianZ]

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

[fantasai]

@SebastianZ Could you give some specific use cases, other than those covered by :user-invalid? :)

[zoliszabo]

@fantasai

Example (copied over from a recent duplicate of this issue):

input {
    font-weight:normal;
}
input:modified {
    font-weight:bold;
}

The above would highlight modified inputs with bold font.

I do not see it less useful than :checked or :default.

[tomhodgins]

Oooh what a fun idea! Here's a quick demo of what using :modified in CSS stylesheets might feel like by using el.value !== el.defaultValue logic in JavaScript with a made-up [--modified] selector in CSS that we can grab onto to implement the functionality: https://codepen.io/tomhodgins/pen/YdKveq

input[--modified] {
  background: lime;
}

It's kind of fun, and does fill a current gap with [value=""] and <input> elements between the value and the dirty value.

[zoliszabo]

Given the above linked dirty value, IMHO the best name for this pseudo-class would be :dirty.

The HTML Live Standard defines the dirty flag as

input and textarea elements have a dirty value flag. This is used to track the interaction between the value and default value. If it is false, value mirrors the default value. If it is true, the default value is ignored.

while select elements have the concept of dirtiness on their option descendants:

The dirtiness of an option element is a boolean state, initially false. It controls whether adding or removing the selected content attribute has any effect.

In this case dirtiness should bubble up from the option elements to their parent select element.

[devmattrick]

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 required attribute along with the :valid selector, but obviously this isn't ideal.

[htstudios]

👍 for :dirty (aka different from what has been submitted by the http response)

[htstudios]

... 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.

[SebastianZ]

As there was a lot of positive feedback and possible use cases mentioned, I set this as Agenda+.

Sebastian

[nt1m]

With :placeholder-shown, :checked, :indeterminate, etc. I'm not sure what's the appeal for this. But I think the bigger issue I have with this, is what the "default" state is.

[zoliszabo]

With :placeholder-shown, :checked, :indeterminate, etc. I'm not sure what's the appeal for this. But I think the bigger issue I have with this, is what the "default" state is.

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. input[checked]:not(:checked) {...} and input:not([checked]):checked {...}), there isn't such a "straightforward" solution in the case of text inputs, textareas or selects.

In the context of :dirty, "default" would mean the value the input field had when the page was loaded (it might be empty or not). It is a good point, however, that in the case of SPAs there should be a way to "mark" a new value as default.

[emilio]

Wouldn't this be equivalent to :is(:user-valid, :user-invalid) or somesuch?

[zoliszabo]

Wouldn't this be equivalent to :is(:user-valid, :user-invalid) or somesuch?

Would you like to shortly explain how this would work?