RE: Suggestion - :changed pseudo-class selecting changed/edited fom fields

I can see how this would be useful, I currently do this for sites to know whether to run certain functions or not (so it is useful outside of just visual feedback). I suggest using :dirty since it is the common terminology used in javascript frameworks that monitor when values have been changed. I do think that we may want to think of ways to make it so that this isn't limited to only form fields, although that is a good starting point.

-----Original Message-----
From: Tab Atkins Jr. [] 
Sent: Monday, March 10, 2014 5:06 PM
To: Dean Trower
Cc: www-style list
Subject: Re: Suggestion - :changed pseudo-class selecting changed/edited fom fields

On Sat, Feb 15, 2014 at 6:25 PM, Dean Trower <> wrote:
> I’d like to suggest the introduction of a new pseudo class:  
> ":changed"  (or perhaps  ":edited" or ":altered" or ":dirty").
> This should apply any form fields that have been changed by the user.
> Specifically, for form inputs that have "value" and "defaultValue"
> properties (all text-like input types, textarea, etc), it should 
> select those where value !== defaultValue.
> For form fields that that have "checked" and "defaultChecked" 
> properties (checkboxes, radio buttons), it should select those where 
> checked !== defaultChecked.
> For <select> inputs, it should select those that contain at least one 
> <option> that has selected !== defaultSelected.
> ...etc.
> The obvious use case is presenting the user with a form to edit 
> existing data (such as a customer record from a database, for example).
> This pseudo-class could be used to provide immediate visible feedback 
> showing which data items have been changed, and hence, whether the 
> user needs to save their edits or not.
> It should be applicable to <form> elements as well, indicating that 
> the form has at least one associated element that matches this pseudo-class.
> (And as an aside, unrelated to selectors, it would be useful to have a 
> boolean property on the <form>'s DOM element that reflects this also, 
> as well as possibly on the elements themselves, as a shortcut for the 
> javascript logic that would otherwise be required).

This sounds like a pretty reasonable suggestion to me.

Thoughts from anyone else?


Received on Tuesday, 11 March 2014 16:15:17 UTC