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

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

Received on Wednesday, 12 March 2014 01:53:37 UTC