W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: [UndoManager] Disallowing live UndoManager on detached nodes

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Wed, 22 Aug 2012 23:08:32 -0700
Message-ID: <5035C8E0.6070005@helsinki.fi>
To: Maciej Stachowiak <mjs@apple.com>
CC: Ojan Vafai <ojan@chromium.org>, Ryosuke Niwa <rniwa@webkit.org>, Glenn Maynard <glenn@zewt.org>, public-webapps <public-webapps@w3.org>, Kentaro Hara <haraken@chromium.org>, Sukolsak Sakshuwong <sukolsak@google.com>, Adam Barth <abarth@webkit.org>, Ehsan Akhgari <ehsan@mozilla.com>, Jonas Sicking <jonas@sicking.cc>, Olli Pettay <Olli.Pettay@helsinki.fi>, Dimitri Glazkov <dglazkov@chromium.org>
On 08/22/2012 10:44 PM, Maciej Stachowiak wrote:
>
> On Aug 22, 2012, at 6:53 PM, Ojan Vafai <ojan@chromium.org <mailto:ojan@chromium.org>> wrote:
>
>> On Wed, Aug 22, 2012 at 6:49 PM, Ryosuke Niwa <rniwa@webkit.org <mailto:rniwa@webkit.org>> wrote:
>>
>>     On Wed, Aug 22, 2012 at 5:55 PM, Glenn Maynard <glenn@zewt.org <mailto:glenn@zewt.org>> wrote:
>>
>>         On Wed, Aug 22, 2012 at 7:36 PM, Maciej Stachowiak <mjs@apple.com <mailto: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.
>
> Depends on the user and their platform of choice. On the Mac I think it's pretty much never the case that changing focus within a window changes your
> undo stack, it either has a shared one or wipes undo history on focus switch. So if GMail forced that, users would probably be surprised. I can
> imagine a use case for having an API that allows multiple undo stacks on platforms where they are appropriate, but merges to a single undo stack on
> platforms where they are not. However, I suspect an API that could handle this automatically would be pretty hairy. So maybe we should handle the
> basic single-undo-stack use case first and then think about complexifying it.


I think the undo-stack per editing context (like <input>) is pretty basics, and certainly something I wouldn't remove from Gecko.
(Largely because using the same undo for separate <input> elements is just very weird, and forcing web apps to use iframes to achieve
  Gecko's current behavior would be horribly complicated.)


-Olli




>
>>         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.
>
> Again, I think it's not right to leave this purely up to the web page. That will lead to web apps that match their developer's platform of choice but
> which don't seem quite right elsewhere.
>
>
> BTW, I don't think the API should impose any requirements on how browsers handle undo for their built-in form controls. I have not read the spec close
> enough to know if that is the case.
>
>
> Regards,
> Maciej
>
Received on Thursday, 23 August 2012 06:09:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:54 GMT