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

defaultValue not always usable.

Consider the scenario when you have, for example, blog article editing
form with <textarea #content> and <button #save>.
By clicking on save you will send current content of textarea
and mark it as not "dirty" but you will *not* want to clear that textarea.

There is also the question what to do with undo/redo stack.
Usually "modified" state for text editors means "non-empty undo stack".

-- 
Andrew Fedoniouk.

http://terrainformatica.com



On Tue, Mar 11, 2014 at 8:11 PM, Dean Trower
<dean@omnivisiontechnology.com> wrote:
> Hence my original suggestion that it selects elements that have value !==
> defaultValue, checked !== defaultChecked, etc.
>
> since defaultValue and defaultChecked can be set via javascript, it's easy
> to "reset" an element to its unmodified state:  Just do defaultValue =
> value.
>
>
> -----Original Message----- From: Andrew Fedoniouk
> Sent: Wednesday, March 12, 2014 12:53 PM
> To: Tab Atkins Jr.
> Cc: Dean Trower ; www-style list
> Subject: 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 04:37:16 UTC