On 08/22/2012 11:16 PM, Maciej Stachowiak wrote:
On Aug 22, 2012, at 11:08 PM, Olli Pettay <olli.pet...@helsinki.fi> wrote:
On 08/22/2012 10:44 PM, Maciej Stachowiak wrote:
On Aug 22, 2012, at 6:53 PM, Ojan Vafai <o...@chromium.org
<mailto:o...@chromium.org>> wrote:
On Wed, Aug 22, 2012 at 6:49 PM, Ryosuke Niwa <rn...@webkit.org
<mailto:rn...@webkit.org>> wrote:
On Wed, Aug 22, 2012 at 5:55 PM, Glenn Maynard <gl...@zewt.org
<mailto:gl...@zewt.org>> wrote:
On Wed, Aug 22, 2012 at 7:36 PM, Maciej Stachowiak <m...@apple.com
<mailto:m...@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.)
It is not. Also some other browser engines behave the same way.
But, again, letting webpages force that behavior in Safari seems wrong to me. I
don't think we should allow violating the platform conventions for
undo so freely. You seem to feel strongly that webpages should be able to align
with the Gecko behavior, but wouldn't it be even worse to let them
forcibly violate the WebKit behavior?
It is not worse either way. Equally bad both ways. But, we're designing a new
API here, so we should make the API as good as possible from the start.
And I think that means allowing multiple undo stack must be in. The default
handling could be somehow platform specific.
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.
Regards, Maciej
