The following elements have an accessible “value” getter, but that value is not accessible as an attribute or as a selector:
textarea
output
button
(maybe I forget a few additional ones)
This makes it harder to style based on their content, unlike their cousins - the input element, which changes its value attribute when its value is set.
The idea would be to have somsething like a .something:value$="123" selector, which would be similar to input.something[value$="123"] but would act upon whatever the value getter represents rather than the particular expression of that in the DOM. In the case of input elements the two would behave in the same way.
Of course!
Here is an example, where a “delete all” button would be hidden if a sibling output field has a zero value.
Today you can only do this with an input or something else that has a value attribute.
In this case you’re setting the value via JavaScript, which sets the value property, not the value attribute, so the [value="0"] attribute selector wouldn’t work either.
Of course, I know, that’s why I’m suggesting a new selector
The idea of the new selector is that it would work on things that have a value property but not necessarily a value attribute, like output/textarea.
Small correction: as Šime is suggesting in his reply, the property that’s reflected on the valueattribute is actually defaultValue, not value.
All in all, your proposal doesn’t seem to be quite security-prone. In the past, we had cases of applications that got exploited because the adopted framework use to reflect the value property of <input> elements on the value attribute, allowing CSS rendering attacks on password inputs (think of [value^='a'] + .x { background: url('a.gif') }. This proposal would lead to the same issue all over again.
Good point re. the password element - I suggest to not enable this on password elements, but only on safer elements like textarea/output. It doesn’t have to have 1:1 mapping with all elements that have a value property, but rather reflect that concept.