Re: [UndoManager] Disallowing live UndoManager on detached nodes

On 08/22/2012 11:28 PM, Ryosuke Niwa wrote:
> On Wed, Aug 22, 2012 at 11:16 PM, Maciej Stachowiak <mjs@apple.com <mailto:mjs@apple.com>> wrote:
>
>
>     On Aug 22, 2012, at 11:08 PM, Olli Pettay <Olli.Pettay@helsinki.fi <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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?

There should be no optional features in this kind of API.


-Olli




>
> - Ryosuke
>

Received on Thursday, 23 August 2012 14:06:09 UTC