- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Wed, 22 Aug 2012 23:08:32 -0700
- 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 UTC