On Wed, Nov 30, 2011 at 6:00 PM, Ryosuke Niwa wrote:
> On Wed, Nov 30, 2011 at 5:38 PM, Jonas Sicking wrote:
>>
>> I actually think it's actively bad to converge on having the same
>> interface for automatic and manual transaction. The two work in
>> dramatically different ways. The code that goe
On Wed, Nov 30, 2011 at 5:38 PM, Jonas Sicking wrote:
>
> I actually think it's actively bad to converge on having the same
> interface for automatic and manual transaction. The two work in
> dramatically different ways. The code that goes into the "apply"
> function of a automatic transaction has
On Wed, Nov 30, 2011 at 1:00 PM, Ryosuke Niwa wrote:
> I initially thought this is a good idea. But then it would make the
> interface for automatic transaction and manual transaction different, and it
> won't help us converging on 3 methods or boolean/string argument.
>
> While I'd like to make s
ine with this proposal.
>
> Cheers,
> Ehsan
>
> - Original Message -
> > From: "Ryosuke Niwa"
> > To: "Jonas Sicking" , "Aryeh Gregor" ,
> "Ojan Vafai" , "whatwg"
> > , "Ehsan Akhgari"
> &g
quot;
> Sent: Wednesday, November 30, 2011 3:05:39 PM
> Subject: Re: [whatwg] Feedback on UndoManager spec
> I've talked about this with Jonas and Ehsan on #whatwg. Jonas made a
> proposal that we can void this issue by renaming automatic
> transaction's apply to "i
I've talked about this with Jonas and Ehsan on #whatwg. Jonas made a
proposal that we can void this issue by renaming automatic transaction's
apply to "implement" (name TBD) without the argument so that we can
differentiate automatic transactions from manual transactions. So we can do:
editor.undo
Calling apply, unapply, and reapply methods for automatic DOM transaction
poses a problem if we merge apply and reapply because now whenever you
define an automatic transaction, you'd have to check the argument and bail
out as needed:
editor.undoManager.transact({apply: function (isReapply) {
i
On Tue, Nov 8, 2011 at 12:44 PM, Ryosuke Niwa wrote:
> I don't think adding noundo solve this problem.
I agree, I abandoned that idea a while ago. It only makes sense if
undo undoes all DOM changes, even if they're outside a transaction.
Otherwise it's pointless. I didn't realize at first that
On Tue, Nov 8, 2011 at 9:14 AM, Aryeh Gregor wrote:
>
> If the behavior is not defined precisely, different browsers will
> behave differently. This means a page might work in one browser, but
> not in another. So authors will write a page, test, find that it
> breaks, and work around the proble
On Tue, Nov 8, 2011 at 11:55 AM, Ryosuke Niwa wrote:
> On Tue, Nov 8, 2011 at 6:12 AM, Aryeh Gregor wrote:
>>
>> > Yeah, it'll be nice if we could define the behavior precisely but then
>> > again, there's nothing that prevents authors from modifying DOM in any
>> > arbitrary way.
>>
>> Right, bu
On Tue, Nov 8, 2011 at 6:12 AM, Aryeh Gregor wrote:
>
> > Yeah, it'll be nice if we could define the behavior precisely but then
> > again, there's nothing that prevents authors from modifying DOM in any
> > arbitrary way.
>
> Right, but at least then it will either work in all browsers or break
On Mon, Nov 7, 2011 at 8:03 PM, Ryosuke Niwa wrote:
>> * "The author must not be forced to deal with manually handling DOM
>> state just because they want to handle non-DOM state."
>
> I disagree with this requirement. This should be an opt-in feature, not
> something forced upon authors.
I think
On Mon, Nov 7, 2011 at 8:27 PM, Jonas Sicking wrote:
> What we should do is to define exactly how the tracking works, and
> what exact operations the browser does to revert a automatic
> transaction.
>
Yeah, it'll be ideal if we could specify that.
For example, if we say that for each node remo
On Mon, Nov 7, 2011 at 5:03 PM, Ryosuke Niwa wrote:
>> Okay, thanks. This is the key point I was missing. Just so I
>> understand, what's supposed to happen here:
>>
>> 1. Some changes get made in an automatic transaction.
>> 2. Some changes get made in no transaction at all, just a script
>> ca
On Mon, Nov 7, 2011 at 12:26 PM, Aryeh Gregor wrote:
> I based it off http://rniwa.com/editing/undomanager-usecases.html,
> plus posts in this thread.
Thanks!
* "The author must not be forced to deal with manually handling DOM
> state just because they want to handle non-DOM state."
I disagr
Okay, I created a wiki page with use-cases and requirements for them:
http://wiki.whatwg.org/wiki/UndoManager_Problem_Descriptions
I based it off http://rniwa.com/editing/undomanager-usecases.html,
plus posts in this thread. I think that the current spec does not
fulfill the following requiremen
On Mon, Nov 7, 2011 at 8:15 AM, Aryeh Gregor wrote:
>
> What you're saying is that maybe there will be parts of the DOM that
> the author doesn't want the UA to touch? In that case, how about we
> let the author specify that UA undo/redo shouldn't affect certain
> subtrees? E.g., have the plane
(sorry for the long delay in responding, life is sometimes flaky for
me right now)
On Fri, Oct 28, 2011 at 3:54 PM, Ryosuke Niwa wrote:
> But that manual transaction may be mutating DOM outside of the editable
> region. i.e. in the slide app case, you may have plane that's showing a list
> of sli
On Fri, Oct 28, 2011 at 12:20 PM, Aryeh Gregor wrote:
> On Fri, Oct 28, 2011 at 2:47 PM, Ojan Vafai wrote:
>> On Fri, Oct 28, 2011 at 11:36 AM, Aryeh Gregor wrote:
>>> It's a few extra characters. I really think the increase in clarity
>>> is worth it. Boolean parameters are much more confusin
On Fri, Oct 28, 2011 at 12:20 PM, Aryeh Gregor wrote:
>
> > Another use-case: a (possibly collaborative) slide editor (e.g. Google
> > Presentations). Imagine that each text box in a slide is a
> contentEditable.
> > You want adding/removing textboxes and/or slides to be manual
> transactions,
>
On Fri, Oct 28, 2011 at 2:47 PM, Ojan Vafai wrote:
> On Fri, Oct 28, 2011 at 11:36 AM, Aryeh Gregor wrote:
>> It's a few extra characters. I really think the increase in clarity
>> is worth it. Boolean parameters are much more confusing, and should
>> be avoided wherever possible.
>
> +1. I'm a
On Fri, Oct 28, 2011 at 11:36 AM, Aryeh Gregor wrote:
> On Fri, Oct 28, 2011 at 12:59 PM, Ryosuke Niwa wrote:
> > I don't want string because then I'd have to do:
> > if (mode == 'reapply')
> > instead of
> > if (isReapply)
> > and the former is much more verbose.
>
> It's a few extra characters
On Fri, Oct 28, 2011 at 12:59 PM, Ryosuke Niwa wrote:
> I don't want string because then I'd have to do:
> if (mode == 'reapply')
> instead of
> if (isReapply)
> and the former is much more verbose.
It's a few extra characters. I really think the increase in clarity
is worth it. Boolean paramet
On Fri, Oct 28, 2011 at 9:37 AM, Aryeh Gregor wrote:
>
> Would everyone be happy if there were no reapply() function, and
> apply() took a string argument that would be either "apply" or
> "reapply"? If the functions are similar, it will be like the status
> quo except without a hard-to-remember
On Thu, Oct 27, 2011 at 6:10 PM, Jonas Sicking wrote:
> Why is it harder to remember one function name and one attribute name,
> than to remember to function names?
Because the function names in this case must be in your code and they
must be correct, or they won't work. That means that when you
On Wed, Oct 26, 2011 at 9:42 AM, Aryeh Gregor wrote:
>
> 9) In section 3.1 Mutations of DOM, you define "DOM changes" and "DOM
> State" by reference to DOM 3. It would be better if you gave explicit
> lists, for clarity. I think the only things that qualify as DOM
> changes to a node are
>
> * C
On Thu, Oct 27, 2011 at 10:48 AM, Aryeh Gregor wrote:
> On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa wrote:
> > I meant properties authors added to nodes. e.g.
> > span.myProperty = true;
> > Should span be removed by some automatic transaction, authors may expect
> it
> > to be restored on und
On Thu, Oct 27, 2011 at 3:10 PM, Jonas Sicking wrote:
> On Thu, Oct 27, 2011 at 11:28 AM, Ojan Vafai wrote:
> > On Thu, Oct 27, 2011 at 10:48 AM, Aryeh Gregor wrote:
> >>
> >> On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa wrote:
> >>
> >> > The same is true for having apply and reapply. Jonas
On Thu, Oct 27, 2011 at 11:28 AM, Ojan Vafai wrote:
> On Thu, Oct 27, 2011 at 10:48 AM, Aryeh Gregor wrote:
>>
>> On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa wrote:
>>
>> > The same is true for having apply and reapply. Jonas wanted to get rid
>> > of
>> > reapply altogether and just have
>> >
On Thu, Oct 27, 2011 at 2:28 PM, Ojan Vafai wrote:
> I disagree. I think the boolean makes things more complicated. Boolean
> arguments stink. Every time you want to use this API you need to go look up
> the documentation to remember whether the boolean is "isReapply" or
> "isApply". There's no su
On Thu, Oct 27, 2011 at 10:48 AM, Aryeh Gregor wrote:
> On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa wrote:
>
> The same is true for having apply and reapply. Jonas wanted to get rid of
> > reapply altogether and just have
> > void apply(in boolean isReapply)
> > In this world, you could do
> >
On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa wrote:
> I meant properties authors added to nodes. e.g.
> span.myProperty = true;
> Should span be removed by some automatic transaction, authors may expect it
> to be restored on undo.
That sounds like the ideal behavior, unless it's too difficult t
On Wed, Oct 26, 2011 at 11:06 PM, Jonas Sicking wrote:
> On Wed, Oct 26, 2011 at 9:06 PM, Ryosuke Niwa wrote:
> > The problem is that if the undo manager has automatic transactions in
> them,
> > then they'll have references to nodes to undo/redo transactions. But
> those
> > nodes's owner docum
On Wed, Oct 26, 2011 at 9:06 PM, Ryosuke Niwa wrote:
> On Wed, Oct 26, 2011 at 8:21 PM, Jonas Sicking wrote:
>>
>> Why is it problematic to move an element with an undoManager from one
>> document to another. If all the data that the undomanager needs lives
>> inside the undoManager object itself
On Wed, Oct 26, 2011 at 8:21 PM, Jonas Sicking wrote:
>
> Why is it problematic to move an element with an undoManager from one
> document to another. If all the data that the undomanager needs lives
> inside the undoManager object itself, it seems quite possible to move
> between documents or eve
On Wed, Oct 26, 2011 at 10:57 AM, Aryeh Gregor wrote:
>>> 15) Is the isReapply parameter to apply() needed? The only place I
>>> see where it's used is if the author specifies a manual transaction
>>> but leaves off a reapply() method. In that case, why not just call
>>> apply() with no extra pa
On Wed, Oct 26, 2011 at 11:39 AM, Ryosuke Niwa wrote:
> On Wed, Oct 26, 2011 at 10:57 AM, Aryeh Gregor wrote:
>>
>> >> 2) What happens if you have an Element with the undoscope attribute
>> >> that doesn't descend from a Document? Does undo management make any
>> >> sense in that case, or should
On Wed, Oct 26, 2011 at 10:13 AM, Ryosuke Niwa wrote:
>> 2) What happens if you have an Element with the undoscope attribute
>> that doesn't descend from a Document? Does undo management make any
>> sense in that case, or should the undoscope attribute have no effect
>> for detached elements?
>
>
On Wed, Oct 26, 2011 at 10:57 AM, Aryeh Gregor wrote:
> >> 2) What happens if you have an Element with the undoscope attribute
> >> that doesn't descend from a Document? Does undo management make any
> >> sense in that case, or should the undoscope attribute have no effect
> >> for detached ele
On Wed, Oct 26, 2011 at 1:13 PM, Ryosuke Niwa wrote:
> This is so that the last transaction is always at position 0, and applying a
> new transaction does not move the position. The position is non-zero only if
> we have not applied any new transactions and have done undo.
Makes sense.
>> 2) Wha
Thanks for a great feedback!
On Wed, Oct 26, 2011 at 9:42 AM, Aryeh Gregor wrote:
>
> 1) I was confused at first by the fact that undo goes backward in the
> history, and redo goes forward. I would have expected that new
> transactions are added to the end of the list, not the beginning.
> This
Things I noticed while reading through it, leaving aside editorial
nitpicks that wouldn't improve clarity:
1) I was confused at first by the fact that undo goes backward in the
history, and redo goes forward. I would have expected that new
transactions are added to the end of the list, not the be
42 matches
Mail list logo
