558090 - CSS input[value="test"] only applys on render

Status: RESOLVED INVALID

(Firefox :: General, enhancement)

Description

[Shaun Forsyth]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)

I know the CSS standard doesn't currently tell you what to do, however IE handles it as I would expect. If use CSS to style an input based on the attribute value hence input[value="test"] this only applys on page render. If the user changes the value of the input element (say type="text" input element) this doesn't update in the DOM, hence the CSS doesn't get removed/added/or updated.

Reproducible: Always

Steps to Reproduce:
1. Add HTML To Page
<input type="text" id="test" value="good">
2. Add CSS To The Page
<style>
input[value="good"] {
border: 1px solid green
}
</style>
3. Load the page, and change the value of the input element. The CSS doesn't get removed. Or change the rule in the CSS to input[value="bad"] and then change input using firefox to bad (type it in) and see that the CSS doesn't update the input element to have a green border.
Actual Results:  
Doesn't update CSS or DOM

Expected Results:  
Update CSS or the DOM which should then update the CSS

I have subbmited this to W3C to try and add it as a defined standard.

Comment 1

[Robert Longson [:longsonr]]

This is correct behavior.  getAttribute('value') returns whatever was in the 
original HTML as the VALUE attribute.  This is the DOM .defaultValue property and 
_does_not_change_ when the text in the element is changed (it's what used to 
"reset" form elements).

resolving invalid.

Comment 3

[James Sleeman]

I would personally say that this is a bug, or at least certainly an undesired
feature. 

For all intents and purposes, when somebody types in the field, one expects
this to be performing the action of changing the attribute.  

Shaun, above, seems to indicate that IE does this in the way I expected (not that I care about IE really).

That said, Opera and Chrome both exhibit Firefox's behavior.  I have also
reported this same bug to Chromium, so will be interesting to see if they treat
it differently.

http://code.google.com/p/chromium/issues/detail?id=44542&sort=-id&colspec=ID%20Stars%20Pri%20Area%20Feature%20Type%20Status%20Summary%20Modified%20Owner%20Mstone%20OS