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
@SebastianZ Could you give some specific use cases, other than those covered by :user-invalid? :)
@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.
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.
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
inputandtextareaelements 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
optionelement is a boolean state, initially false. It controls whether adding or removing theselectedcontent attribute has any effect.
In this case dirtiness should bubble up from the option elements to their parent select element.
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.
馃憤 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.