Re: [UndoManager] Disallowing live UndoManager on detached nodes

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