Hi all,
I've added more examples to the document:
http://rniwa.com/editing/undomanager.html and also requested feedback on
public-webapps. As of this revision, I consider the specification is ready
for implementation feedback. I will start prototyping it for WebKit and
start writing tests.
I
More updates! http://rniwa.com/editing/undomanager.html
Summary of changes on Dec 1st, 2011:
- UndoManager's item(n) now always returns an array
- Changes to DOMTransaction
- apply no longer has isReapply argument.
- apply, reapply, unapply on DOMTransaction has been renamed to
Hi all,
I've uploaded the draft: http://rniwa.com/editing/undomanager.html to
reflect the discussions so far.
Summary of changes:
- Automatic transaction now calls unapply and reapply methods (note:
this is problematic with apply(isReapply) because now authors have to check
the
On Thu, Oct 27, 2011 at 9:06 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Oct 27, 2011 at 6:22 PM, Jonas Sicking jo...@sicking.cc wrote:
Wait, the last bullet point doesn't mean that changes to IDL
properties are in general rolled back, does it? That would be
extremely hard to implement
On Fri, Oct 28, 2011 at 12:06 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Oct 27, 2011 at 9:06 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Oct 27, 2011 at 6:22 PM, Jonas Sicking jo...@sicking.cc wrote:
Wait, the last bullet point doesn't mean that changes to IDL
properties are
On Fri, Oct 28, 2011 at 3:06 AM, Jonas Sicking jo...@sicking.cc wrote:
I'm not sure what you are trying to say.
I think he means to say that custom IDL properties added by authors
have to persist. I'm not sure there's any official name for them in
standards, but I've heard them called expando
On Fri, Oct 28, 2011 at 12:42 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Oct 28, 2011 at 12:06 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Oct 27, 2011 at 9:06 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Oct 27, 2011 at 6:22 PM, Jonas Sicking jo...@sicking.cc wrote:
Wait,
On Fri, Oct 28, 2011 at 1:21 PM, Jonas Sicking jo...@sicking.cc wrote:
Ah.
Just say that the *same* node is returned or inserted or whatever. A
node that just looks the same is not the same node.
I guess I can say that two DOM states of a node are equal only if all
descendent nodes
On Fri, Oct 28, 2011 at 1:25 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Oct 28, 2011 at 1:21 PM, Jonas Sicking jo...@sicking.cc wrote:
Ah.
Just say that the *same* node is returned or inserted or whatever. A
node that just looks the same is not the same node.
I guess I can say that
Hi all,
I've updated the document: http://rniwa.com/editing/undomanager.html per
discussions.
Summary of changes:
- transaction is renamed to DOM transaction
- The value of isAutomatic is read immediately before the transaction is
applied
- Swapped the definition of clearUndo and
On Thu, Oct 27, 2011 at 4:23 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hi all,
I've updated the document: http://rniwa.com/editing/undomanager.html per
discussions.
Summary of changes:
transaction is renamed to DOM transaction
The value of isAutomatic is read immediately before the
On Thu, Oct 27, 2011 at 6:22 PM, Jonas Sicking jo...@sicking.cc wrote:
Wait, the last bullet point doesn't mean that changes to IDL
properties are in general rolled back, does it? That would be
extremely hard to implement in general. It also creates all sorts of
weird behavior. Would you for
Hi all,
I've updated the document: http://rniwa.com/editing/undomanager.html
Summary of changes:
- The undoscope content attribute is now ignored on an editable element
unless it is an editing host. Sections 2.1 and 2.2 have been updated to
reflect this change.
- *Section 3.2
Hi all,
I've uploaded my proposal: http://rniwa.com/editing/undomanager.html
Summary of changes:
- *Section 3.2 Automatic transactions* is rewritten
- Removed *A proper sequence of automatic transactions*
- Added *3.2.1. Undoability and Redoability of Automatic
Transactions*to
On Tue, Sep 20, 2011 at 10:13 PM, Ryosuke Niwa rn...@webkit.org wrote:
void apply(in boolean isReapply)
I haven't been following the substance of apply vs. reapply etc., but
as I said before, could you not make this a boolean argument? How are
authors supposed to remember whether it's
So the argument is that authors will never call apply themselves. Only
browsers would. If you can come up with a use case where authors need to
call apply function with a boolean value, then I'm more than happy to drop
the boolean argument and just have apply, unapply, reapply.
- Ryosuke
On Wed,
So apply, unapply, and reapply are callback functions supplied by authors
and called by UAs.
e.g.
myUndoScope.undoManager.transact({
apply: function() {alert('done');},
unapply: function() {alert('undone');},
reapply: function() {alert('redone');}
})
the above code inserts a new
There's nothing wrong with the idl specifying apply(DOMString reason);
Reason will be for normal applications and reapply for reapply cases.
That still gives you a truth value, and it gives something more
meaningful to callees.
On 9/21/11, Ryosuke Niwa rn...@webkit.org wrote:
So the argument
On Wed, Sep 21, 2011 at 1:30 PM, timeless timel...@gmail.com wrote:
There's nothing wrong with the idl specifying apply(DOMString reason);
Reason will be for normal applications and reapply for reapply cases.
That still gives you a truth value, and it gives something more
meaningful to
On Wed, Sep 21, 2011 at 12:58 PM, Ryosuke Niwa rn...@webkit.org wrote:
So apply, unapply, and reapply are callback functions supplied by authors
and called by UAs.
e.g.
myUndoScope.undoManager.transact({
apply: function() {alert('done');},
unapply: function() {alert('undone');},
I had a discussion with Jonas on IRC and we've come to a conclusion that we
should have both boolean argument and reapply.
The rationale is that if apply/reapply share most code and only requires
some work before/after the shared code, then reapply can simply call apply
inside. On the other hand
On Mon, Sep 12, 2011 at 6:06 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Sep 12, 2011 at 5:19 PM, Jonas Sicking jo...@sicking.cc wrote:
Could you please supply an example where the apply/reapply split leads
to cleaner or otherwise better code than using a boolean argument?
apply:
I must say that I'm a little sad about the fact I have to tie transactions
so closely with undo manager.
In my original proposal where we have AbstractTransaction interface and two
derived interfaces for automatic and manual transactions, I tried to
decouple the concepts of undomanager and
On Mon, Sep 12, 2011 at 8:19 PM, Jonas Sicking jo...@sicking.cc wrote:
Could you please supply an example where the apply/reapply split leads
to cleaner or otherwise better code than using a boolean argument?
Boolean arguments are evil and should be avoided wherever possible.
It's impossible to
On 11-09-11 10:00 PM, Ryosuke Niwa wrote:
On Tue, Aug 30, 2011 at 12:15 PM, Ryosuke Niwarn...@webkit.org wrote:
4. Jonas requested that we have manualTransact and managedTransact instead
of single transact on undoManager for clarity. I think this is a good idea
but I'd rather settle the
On Mon, Sep 12, 2011 at 1:31 PM, Ehsan Akhgari eh...@mozilla.com wrote:
On 11-09-11 10:00 PM, Ryosuke Niwa wrote:
On Tue, Aug 30, 2011 at 12:15 PM, Ryosuke Niwarn...@webkit.org wrote:
4. Jonas requested that we have manualTransact and managedTransact
instead
of single transact on
On Sat, Sep 10, 2011 at 7:01 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 30, 2011 at 7:22 PM, Jonas Sicking jo...@sicking.cc wrote:
I'm really failing to think of a case when you'd really want to have
apply and reapply as separate callbacks. Even in the most trivial
cases it seems
On Mon, Sep 12, 2011 at 5:19 PM, Jonas Sicking jo...@sicking.cc wrote:
Could you please supply an example where the apply/reapply split leads
to cleaner or otherwise better code than using a boolean argument?
apply: function() {
// modify dom
// send data back to server
},
unapply:
Hi all,
I've updated the working draft: http://rniwa.com/editing/undomanager.html
The summary of changes:
- Managed transaction has been renamed to automatic transaction
- Moved undoManager IDL attribute from Node to Element and Document
- Automatic transactions no longer undo/redo DOM
There's too much good stuff going on, both in the specs, and in my own
project. :-) I noticed Ehsan's blog post about editing on the Web,
http://ehsanakhgari.org/blog/2011-08-31/future-editing-web . I'm groaning
because I haven't been involved! :-p
A few thoughts on my mind:
1. I think we
On Thu, Sep 1, 2011 at 6:26 AM, Alex Vincent ajvinc...@gmail.com wrote:
3. I just spotted a flaw in our API's. Imagine the following:
-
myEditor.undoManager.transact({apply: function () {
insert(document.createTextNode('o')) }, label: 'First transaction'});
On Thu, Sep 1, 2011 at 11:36 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Sep 1, 2011 at 6:26 AM, Alex Vincent ajvinc...@gmail.com wrote:
1. I think we should start writing a test suite, for two reasons.
First,
to get some idea how this works in practice, with a reference
On Thu, Sep 1, 2011 at 11:55 AM, Alex Vincent ajvinc...@gmail.com wrote:
On Thu, Sep 1, 2011 at 11:36 AM, Ryosuke Niwa rn...@webkit.org wrote:
Implementing it in JavaScript will be somewhat challenging because
managed/automatic transactions need to keep track of all changes made by a
On 11-08-25 7:06 PM, Ian Hickson wrote:
- We need to figure out how UndoManager objects affect the bfcache and
the document salvageable flag. Please ping me on IRC about this.
Would you mind sharing the results of that conversation, please (in case
it has happened yet). Thanks!
Ehsan
On Tue, Aug 30, 2011 at 11:52 AM, Ryosuke Niwa rn...@webkit.org wrote:
- must return the object implementing the UndoManager interface should
probably clarify _which_ object. There's presumably more than one
object in the world implementing this interface. :-)
Oh, yes. I'll clarify
On Tue, Aug 30, 2011 at 12:21 PM, Ehsan Akhgari eh...@mozilla.com wrote:
On 11-08-30 3:15 PM, Ryosuke Niwa wrote:
1. Should Transaction have reapply property or not? It appears that
some
of us (e.g. me, Annie, Alex) want it for semantical clarity while
others
(e.g. Jonas and
On Tue, Aug 30, 2011 at 12:30 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 30, 2011 at 12:21 PM, Ehsan Akhgari eh...@mozilla.com wrote:
On 11-08-30 3:15 PM, Ryosuke Niwa wrote:
1. Should Transaction have reapply property or not? It appears that
some
of us (e.g. me, Annie,
On Tue, 30 Aug 2011 21:04:09 +0200, Ryosuke Niwa rn...@webkit.org wrote:
I've updated my document: https://rniwa.com/editing/undomanager.html
I clarified which object it should return and also moved undoManager idl
attribute from Element/Document to Node as we have agreed.
I missed this
On Friday, August 12, 2011, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Aug 12, 2011 at 3:11 PM, Ehsan Akhgari eh...@mozilla.com wrote:
On 11-08-12 6:10 PM, Ryosuke Niwa wrote:
But having authors add flag in almost all cases isn't that nice either.
Why do you think that authors need to
On 11-08-11 6:07 PM, Jonas Sicking wrote:
On Thu, Aug 11, 2011 at 2:56 PM, Ryosuke Niwarn...@webkit.org wrote:
On Thu, Aug 11, 2011 at 2:53 PM, Ehsan Akhgarieh...@mozilla.com wrote:
I think the confusion is arising because you chose to attach undoManager
to elements, not nodes. Note that
On 11-08-09 6:36 PM, Jonas Sicking wrote:
On Tue, Aug 9, 2011 at 3:11 PM, Ryosuke Niwarn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 2:55 PM, Jonas Sickingjo...@sicking.cc wrote:
I don't think it's a matter of which use cases can or can't be solved with
either solution. It's pretty clear to
On Fri, Aug 12, 2011 at 3:07 PM, Ehsan Akhgari eh...@mozilla.com wrote:
On 11-08-09 6:36 PM, Jonas Sicking wrote:
Sure, your API is more convenient in certain situations. But it also
encourages code duplication (I'll note that in the examples you
originally provided in this thread you always
On 11-08-12 6:10 PM, Ryosuke Niwa wrote:
On Fri, Aug 12, 2011 at 3:07 PM, Ehsan Akhgarieh...@mozilla.com wrote:
On 11-08-09 6:36 PM, Jonas Sicking wrote:
Sure, your API is more convenient in certain situations. But it also
encourages code duplication (I'll note that in the examples you
On Fri, Aug 12, 2011 at 3:11 PM, Ehsan Akhgari eh...@mozilla.com wrote:
On 11-08-12 6:10 PM, Ryosuke Niwa wrote:
But having authors add flag in almost all cases isn't that nice either.
Why do you think that authors need to specify the flag in almost all cases?
Because almost all text
On 11-08-05 1:01 PM, Ryosuke Niwa wrote:
On Fri, Aug 5, 2011 at 9:57 AM, Jonas Sickingjo...@sicking.cc wrote:
Why treat documentElement specially here? Just make the documentElement
*not* have a undoManager by default and have it just use it's ancestor's,
just like all other elements.
The
On Thu, Aug 11, 2011 at 2:53 PM, Ehsan Akhgari eh...@mozilla.com wrote:
I think the confusion is arising because you chose to attach undoManager to
elements, not nodes. Note that document _is_ a node in the DOM, but it's
not an element. I think we should just modify the spec to attach
On Thu, Aug 11, 2011 at 2:56 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Aug 11, 2011 at 2:53 PM, Ehsan Akhgari eh...@mozilla.com wrote:
I think the confusion is arising because you chose to attach undoManager
to elements, not nodes. Note that document _is_ a node in the DOM, but it's
On Tue, Aug 9, 2011 at 3:36 PM, Jonas Sicking jo...@sicking.cc wrote:
I do definitely agree that making the reapply function optional helps
a lot in that at least pages don't have to worry about the feature if
they're not using it. If we do that though we should probably rename
the 'apply'
On Fri, Aug 5, 2011 at 7:12 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 5, 2011 at 5:17 PM, Ryosuke Niwa rn...@webkit.org wrote
You're right that you can redo what the UA did after you unapplied the
managed transaction UA inserted. So maybe replace isn't really that
useful after
Hi everyone,
I have updated my document on http://rniwa.com/editing/undomanager.html to
address all responses I've got so far. Most of it is about clarifying
details and adding some examples.
Now, I'd really like to get your opinions on what event(s) we should have
for this to work. The
On Tue, Aug 9, 2011 at 12:31 AM, Jonas Sicking jo...@sicking.cc wrote:
I still see UndoManager.replace in there. I still haven't heard any use
cases that won't be solved better with a beforeEditingAction event (and
solved ok simply using the undo() function until we have a
beforeEditingAction
On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 9, 2011 at 12:42 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 12:31 AM, Jonas Sicking jo...@sicking.cc wrote:
Likewise I still haven't heard of any examples where the apply function
isn't
On Tue, Aug 9, 2011 at 12:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 9, 2011 at 12:42 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 12:31 AM, Jonas Sicking jo...@sicking.cc
wrote:
On Tue, Aug 9, 2011 at 1:59 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 9, 2011 at 12:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 9, 2011 at 12:42 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue,
On Tue, Aug 9, 2011 at 2:44 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 1:59 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 9, 2011 at 12:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug
On Tue, Aug 9, 2011 at 4:59 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 9, 2011 at 12:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 9, 2011 at 12:42 AM, Ryosuke Niwa rn...@webkit.org wrote:
On
On Tue, Aug 9, 2011 at 2:55 PM, Jonas Sicking jo...@sicking.cc wrote:
I don't think it's a matter of which use cases can or can't be solved with
either solution. It's pretty clear to me that all scenarios can be solved
with either API.
Right, they're isomorphic.
It's just a matter of which
On Tue, Aug 9, 2011 at 2:59 PM, Annie Sullivan sulli...@google.com wrote:
On Tue, Aug 9, 2011 at 4:59 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 9, 2011 at 12:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking jo...@sicking.cc wrote:
On
On Tue, Aug 9, 2011 at 3:11 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 2:55 PM, Jonas Sicking jo...@sicking.cc wrote:
I don't think it's a matter of which use cases can or can't be solved with
either solution. It's pretty clear to me that all scenarios can be solved
with
On Tue, Aug 9, 2011 at 3:29 PM, Annie Sullivan sulli...@chromium.org wrote:
On Tue, Aug 9, 2011 at 6:25 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 9, 2011 at 2:59 PM, Annie Sullivan sulli...@google.com
wrote:
On Tue, Aug 9, 2011 at 4:59 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, 05 Aug 2011 02:31:10 +0200, Ryosuke Niwa rn...@webkit.org wrote:
Not sure. This happens all the time in design mode. We've had plenty of
crash reports that only reproduce when there are no document element.
It might also be hard to implement such a behavior in WebKit at least
because
On Fri, Aug 5, 2011 at 9:57 AM, Jonas Sicking jo...@sicking.cc wrote:
Why treat documentElement specially here? Just make the documentElement
*not* have a undoManager by default and have it just use it's ancestor's,
just like all other elements.
The document is an ancestor of the
On Fri, Aug 5, 2011 at 10:01 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Aug 5, 2011 at 9:57 AM, Jonas Sicking jo...@sicking.cc wrote:
Why treat documentElement specially here? Just make the documentElement
*not* have a undoManager by default and have it just use it's ancestor's,
just
Why is there a need for a 'reapply' action? How is it different from
the 'apply' action?
In the case of collaborative editing apps, reapply is different from apply
because the backend server may have a tree of transaction history and may
need to consult on demand in order to determine
On Fri, Aug 5, 2011 at 1:59 PM, Jonas Sicking jo...@sicking.cc wrote:
In the case of collaborative editing apps, reapply is different from
apply because the backend server may have a tree of transaction history and
may need to consult on demand in order to determine exactly what mutations
On Fri, Aug 5, 2011 at 2:40 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Aug 5, 2011 at 1:59 PM, Jonas Sicking jo...@sicking.cc wrote:
In the case of collaborative editing apps, reapply is different from
apply because the backend server may have a tree of transaction history and
may
On Fri, Aug 5, 2011 at 5:06 PM, Jonas Sicking jo...@sicking.cc wrote:
Though I guess you can always supply the same function for apply and
reapply, but that means you can't use the convenient inline syntax
that you've used in your examples.
Or does 'reapply' default to the 'apply' function
On Fri, Aug 5, 2011 at 5:17 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Aug 5, 2011 at 5:06 PM, Jonas Sicking jo...@sicking.cc wrote:
For example in the collaborative editing case I would think that the
page generally wants to get a semantic understanding of the editing
operations so that
On Wed, Aug 3, 2011 at 2:46 PM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 03 Aug 2011 23:40:27 +0200, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Aug 3, 2011 at 2:36 PM, Anne van Kesteren ann...@opera.com
wrote:
If they are identical I think it is even more clear we should remove
On Wed, 03 Aug 2011 00:02:58 +0200, Ehsan Akhgari eh...@mozilla.com
wrote:
By this definition, it's ambiguous what needs to happen to the
documentElement's undoScope attribute, since it doesn't have an element
ancestor. I think we should just clarify that in that case, the value
is true,
On Tue, Aug 2, 2011 at 2:43 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 2, 2011 at 2:32 PM, Eric U er...@google.com wrote:
Could you add an example of the user typing e.g. h
... e ... l ... l ... o, via an app that's doing the DOM
modifications, using managed transactions, such that
On 11-08-03 2:55 AM, Anne van Kesteren wrote:
On Wed, 03 Aug 2011 00:02:58 +0200, Ehsan Akhgari eh...@mozilla.com
wrote:
By this definition, it's ambiguous what needs to happen to the
documentElement's undoScope attribute, since it doesn't have an
element ancestor. I think we should just
On Wed, 03 Aug 2011 22:42:25 +0200, Ehsan Akhgari eh...@mozilla.com
wrote:
You mean contentEditable and undoScope? That would prohibit the use
case of a web application which is not using contentEditable taking
advantage of UndoManager...
I meant merging document.undoManager and
On Wed, Aug 3, 2011 at 2:18 PM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 03 Aug 2011 22:42:25 +0200, Ehsan Akhgari eh...@mozilla.com
wrote:
You mean contentEditable and undoScope? That would prohibit the use case
of a web application which is not using contentEditable taking
On Wed, 03 Aug 2011 23:30:59 +0200, Ryosuke Niwa rn...@webkit.org wrote:
I meant those to be identical. I should probably clarify that.
If they are identical I think it is even more clear we should remove the
one on Document as it's redundant :-)
--
Anne van Kesteren
On Wed, Aug 3, 2011 at 2:36 PM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 03 Aug 2011 23:30:59 +0200, Ryosuke Niwa rn...@webkit.org wrote:
I meant those to be identical. I should probably clarify that.
If they are identical I think it is even more clear we should remove the
one on
On Wed, 03 Aug 2011 23:40:27 +0200, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Aug 3, 2011 at 2:36 PM, Anne van Kesteren ann...@opera.com
wrote:
If they are identical I think it is even more clear we should remove the
one on Document as it's redundant :-)
Mn... but I think it's more
This is a very nice proposal; thanks for working on this, Ryosuke! I
have a number of questions and concerns on it, and I would appreciate if
you can comment on these:
1. The definition of @undoscope seems to not address the question of
whether the document element should be an Undo Scope or
On Tue, Aug 2, 2011 at 11:30 AM, Ehsan Akhgari eh...@mozilla.com wrote:
This is a very nice proposal; thanks for working on this, Ryosuke! I have
a number of questions and concerns on it, and I would appreciate if you can
comment on these:
Nope! I just REALLY want to fix this.
1. The
On Tue, Aug 2, 2011 at 1:51 PM, Eric U er...@google.com wrote:
I think the manual transaction is what I'd want to make undo/redo in
the edit menu work with jV
[https://addons.mozilla.org/en-US/firefox/addon/jv/]*.
That's great to hear! I've spent so much time reconciling the way managed
On Tue, Aug 2, 2011 at 2:17 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 2, 2011 at 1:51 PM, Eric U er...@google.com wrote:
I think the manual transaction is what I'd want to make undo/redo in
the edit menu work with jV
[https://addons.mozilla.org/en-US/firefox/addon/jv/]*.
That's
On Tue, Jul 26, 2011 at 11:34 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hi all,
In the last couple of weeks, I've been working with developers of CKEditor,
TinyMCE, and Google Docs to come up with new API for undo and redo.
Why? Because undo and redo are broken on the Web today. Whenever Web
On Fri, Jul 29, 2011 at 5:08 PM, Jonas Sicking jo...@sicking.cc wrote:
I really do like the undoscope attribute, that is something that is
definitely needed.
Yes. I've considered other possibilities such as letting scripts to manually
instantiate UndoManager objects, etc... but that turned
On Wed, Jul 27, 2011 at 11:44 PM, Alex Vincent ajvinc...@gmail.com wrote:
I'm seeing one major hole in your interface: you don't clearly specify how
to *end* a transaction group. This really matters for when I want to
start a group manually, do a bunch of little things, and then end the
Hi all,
In the last couple of weeks, I've been working with developers of CKEditor,
TinyMCE, and Google Docs to come up with *new API for undo and redo*.
Why? Because* undo and redo are broken on the Web today*. Whenever Web apps
try to add a custom editing operation without using execCommand or
In the last couple of weeks, I've been working with developers of CKEditor,
TinyMCE, and Google Docs to come up with *new API for undo and redo*.
I'd like to take a look at this and be very closely involved in this
specification. About a month ago, I wrote this:
On Wed, Jul 27, 2011 at 8:34 PM, Alex Vincent ajvinc...@gmail.com wrote:
I'd like to take a look at this and be very closely involved in this
specification. About a month ago, I wrote this:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031191.html
Oh, yes. I do remember
87 matches
Mail list logo
