[whatwg] Automatic transaction should support changing the value of input/textarea

[Jonas Sicking]

On Sun, Nov 27, 2011 at 10:22 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> On Sun, Nov 27, 2011 at 10:13 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> Another option is to say that if the textarea value is any other value
>> than the "after" value when a automatic transaction is undone, it
>> doesn't do anything.
>
>
> Yeah, I've thought about this as well. However, the UA has to store the
> original data anyway because we can have scenarios like:
>
> input.value is set to "foo"
> Script runs input.value = "hi" inside an automatic transaction
> Another script modifies it to "foo bar"
> Yet another script modifies it to "hi"
>
> At this point, input.value is "hi" and matches the "after" value in step 2.
> However, natively undoing the transaction won't get us anywhere.
>
> Or did I misunderstand something?

I don't think I'm understanding your set of steps.

Let me try to clarify:

1. input.value is "foo".
2. automatic transaction starts.
3. input.value is changed to "hi".
4. automatic transaction ends.
5. input.value is changed to "foo bar".
6. input.value is changed to "hi".
7. undo is called on undomanager.

at this point I don't see a reason we wouldn't want to change the
value back to "foo". This doesn't seem like a particularly interesting
scenario because the change is perfectly undoable since the value
matches.

Is there a use-case where we wouldn't want the undo to revert the
value to "foo"?

The more interesting scenario that I was concerned about was:

1. input.value is "lot's of text here".
2. automatic transaction starts.
3. input.value is changed to "lot's of words here".
4. automatic transaction ends.
5. input.value is changed to "some words here".
6. undo is called on undomanager.

Here it seems like there is "no perfect solution" since we don't know
if the page would want to revert back to "lot's of text here", or keep
the "some words here". Or maybe change to "some text here" (though
this obviously isn't a viable solution since it'll too easily break in
non-trivial scenarios).

If we define that the implementation has to revert the value back to
"lot's of text here" it means that the implementation must store the
"delta" as well as either the whole "before value" or the whole "after
value". Or store both the "before value" and "after value" and no
delta.

If we define that the implementation should leave the value untouched
then the implementation only needs to store a hash of the "after"
value and the "delta".

Storing the whole "after value" or "before value" *might* be a lot of
data. Especially if editing a long piece of text and doing a lot of
small edits.

But maybe it's not enough of a problem to worry about. Implementations
do have the ability to compress the values in-memory which will likely
dramatically reduce the amount of space needed, especially for large
bodies of human readable text.

/ Jonas