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

Re: [UndoManager] Disallowing live UndoManager on detached nodes

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Wed, 22 Aug 2012 23:28:03 -0700
Message-ID: <CABNRm62XMHS0Ki3ncgdyAYoE47QBJpeq+H3NoqC78zNT1BxP0A@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: olli@pettay.fi, Ojan Vafai <ojan@chromium.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 Wed, Aug 22, 2012 at 11:16 PM, Maciej Stachowiak <mjs@apple.com> wrote:

> On Aug 22, 2012, at 11:08 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
> > 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.)
> It might be ok to let Web pages conditionally get Gecko-like separate undo
> stack behavior inside Firefox, at least on Windows. (Firefox even seems to
> do per-field undo on Mac, so I'm starting to think that it's more of a
> Gecko quirk than a Windows platform thing.)

> So if there is an API for separate undo stacks, it has to handle the case
> where there's really a single undo stack. And that would potentially be
> hard to program with.
> On the other hand, there are certainly use cases where a single global
> undo stack is right (such as a page with a single rich text editor). And
> it's easy to handle those cases without adding a lot of complexity. And if
> we get that right, we could try to add on something for conditional
> multiple undo stacks.

Maybe the solution is as simple as to make undoscope content attribute an
optional feature. Browsers/platforms that can have multiple undo managers
within a single document will support undoscope content attribute, and
those that can't won't support it. Authors will then feature-detect
undoscope content attribute and support both cases.

What do you guys think?

- Ryosuke
Received on Thursday, 23 August 2012 06:36:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:38 UTC