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

On Tue, Mar 11, 2014 at 9:53 PM, Andrew Fedoniouk <news@terrainformatica.com
> wrote:

> On Mon, Mar 10, 2014 at 5:06 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
> > On Sat, Feb 15, 2014 at 6:25 PM, Dean Trower
> > <dean@omnivisiontechnology.com> 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?
> >
>
> About the name: I believe ':modified' better matches the purpose. As
> user may edit content of some textarea by typing "abc" and removing
> these three characters after. Will it be "edited" after that?
>
> In general such state flag make sense but without mechanism of
> resetting it back to unmodified state it is barely useful.
> Think about SPA use cases when <form> is reused for multiple "edit
> sessions" without reloading the page. Before each session the flag
> needs to be reset.
>
> In general that could be accomplished if DOM API would have something like
> Element.state.modified = false;
>
> And practice shows that API to all other state flags is also quite
> useful. Sciter, for example, has these:
> http://terrainformatica.com/sciter/dom/States.whtm
>
> --
> Andrew Fedoniouk.
>
> http://terrainformatica.com
>
>

If we're bike-shedding, I'd like to throw down with :dirty, the reason
being that modified could be confused as an event and then how it fits into
pseudo (enters/leaves) gets confusing.  But an element is simply in the
dirty state or it isn't.  As he originally requested it be simply based on
whether it matches the default values or not.  In terms of an SPA, you
would have to manage the defaults and values anyway, so that makes sense
too.



-- 
Brian Kardell :: @briankardell :: hitchjs.com