On 08/22/2012 10:44 PM, Maciej Stachowiak wrote:
On Aug 22, 2012, at 6:53 PM, Ojan Vafai <[email protected]
<mailto:[email protected]>> wrote:
On Wed, Aug 22, 2012 at 6:49 PM, Ryosuke Niwa <[email protected]
<mailto:[email protected]>> wrote:
On Wed, Aug 22, 2012 at 5:55 PM, Glenn Maynard <[email protected]
<mailto:[email protected]>> wrote:
On Wed, Aug 22, 2012 at 7:36 PM, Maciej Stachowiak <[email protected]
<mailto:[email protected]>> 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
