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

On Tue, Mar 11, 2014 at 10:33 PM, Doin <doin@omnivisiontechnology.com> wrote:
> I believe <textarea>s have a defaultValue as well, do they not?
>
> From the Mozilla docs:
>
>            defaultValue     DOMString     The control's default value, which
> behaves like the element.textContent property.
>
> See also the DOM level 2 HTML spec.
>
> (Just FYI, I checked and in FF27 .defaultValue and .textContent always hold
> the same value, whichever you set; but in IE11 they can change
> independently).
>
> -
>
> Also, the "modified" state doesn't necessarily reflect the undo/redo stack,
> because
>
> (a) it depends on when you last saved your changes, and
> (b) You can revert changes other than by clicking "Undo" (e.g. typing a
> letter followed by a backspace) so a non-empty stack isn't a reliable
> indicator of actual content changes.
>
> (I'm aware that most text editors would consider my example in (b) as dirty
> (unsaved changes) anyway, but I don't think it's necessary to do so, and in
> this case wouldn't be feasible without making the whole undo/redo stack an
> intrinsic part of the DOM.  Which I dunno, might actually be an idea ---
> <textarea>.undo(n), <textarea>.redo(n) anyone??? - but that'd be a much,
> much bigger change than what I'm suggesting!)
>
> The idea is that when you click on <button #save>, your code does 2 things:
> (1) Posts the data to the server, and (2) sets <textarea
> #content>.defaultValue = <textarea #content>.value, which automatically
> clears the "dirty" flag (and all associated CSS styling) for you.  It
> doesn't clear the textarea's current value, and it doesn't affect the
> undo/redo stack, if you've implemented one; an undo or redo following a save
> simply re-dirties the textarea.
>

1. "default value" as an entity is not always available (e.g. contenteditable
    editing behavior).
2. Content comparison when used for "modified" state purposes is not always
    reliable. For example contenteditable editor content may look the
    same (after some manipulations) for the human but have substantially
    different DOM content for the comparison purposes.
3. It appears that the only reliable "modified" criteria for non-trivial inputs
    is non-zero depth of undo stack.
4. Thus ":modified" shall have clear definition of "modification" as a concept
    and probably on per input behavior basis. "modified since when" or
   "modified relative to what"? What to use.

It appears as these questions shall be addressed to html/webapp WGs rather
than to CSS.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

>
> -----Original Message----- From: Andrew Fedoniouk
> Sent: Wednesday, March 12, 2014 3:36 PM
> To: Dean Trower
> Cc: Tab Atkins Jr. ; www-style list
> Subject: 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 06:24:22 UTC