On Wed, Aug 22, 2012 at 6:49 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:
> On Wed, Aug 22, 2012 at 5:55 PM, Glenn Maynard <glenn@zewt.org> wrote:
>
>> On Wed, Aug 22, 2012 at 7:36 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>>
>>> Ryosuke also raised the possibility of multiple text fields having
>>> separate UndoManagers. On Mac, most apps wipe they undo queue when you
>>> change text field focus. WebKit preserves a single undo queue across text
>>> fields, so that tabbing out does not kill your ability to undo. I don't
>>> know of any app where you get separate switchable persistent undo queues.
>>> Thins are similar on iOS.
>>>
>>
Think of the use-case of a threaded email client where you can reply to any
message in the thread. If it shows your composing mails inline (e.g. as
gmail does), the most common user expectation IMO is that each email gets
it's own undo stack. If you undo the whole stack in one email you wouldn't
expect the next undo to start undo stuff in another composing mail. In
either case, since there's a simple workaround (seamless iframes), I don't
think we need the added complexity of the attribute.
> Firefox in Windows has a separate undo list for each input. I would find
>> a single undo list strange.
>>
>
> Internet Explorer and WebKit don't.
>
> While we're probably all biased to think that what we're used to is the
> best behavior, it's important to design our API so that implementors need
> not to violate platform conventions. In this case, it might mean that
> whether text field has its own undo manager by default depends on the
> platform convention.
>
Also, another option is that we could allow shadow DOMs to have their own
undo stack. So, you can make a control that has it's own undo stack if you
want.