UndoManager Problem Descriptions - Revision history

Aryeh Gregor: /* Collaborative editing */ Update requirement to leave it up in the air

2011-11-07T20:24:09Z

Collaborative editing: Update requirement to leave it up in the air

← Older revision		Revision as of 20:24, 7 November 2011
Line 53:		Line 53:

	* The author must be able to decide exactly how undo/redo are executed if they so choose. They might want to use application-specific heuristics to undo changes when there are conflicts.		* The author must be able to decide exactly how undo/redo are executed if they so choose. They might want to use application-specific heuristics to undo changes when there are conflicts.
	* If browsers try to merge changes themselves, the algorithm should be well-defined if possible. Otherwise it will just confuse authors and not be useful, because it will succeed in some browsers and fail in others, or have unpredictable results. ~~However,~~ this ~~might be impossible~~ to ~~attain, because authors can always make DOM changes outside of any transaction, and thereby mess everything up~~.		* If browsers try to merge changes themselves, the algorithm should be well-defined if possible. Otherwise it will just confuse authors and not be useful, because it will succeed in some browsers and fail in others, or have unpredictable results. '''Issue:''' Is this doable? Refer to mailing list discussion.
	* It must be possible to have some parts of the page author-controlled, and some parts of the page UA-controlled. For instance, there might be a collaborative editor on the same page as some unrelated inputs.		* It must be possible to have some parts of the page author-controlled, and some parts of the page UA-controlled. For instance, there might be a collaborative editor on the same page as some unrelated inputs.
	* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the parts of the page that are collaboratively edited, there is no reason for the UA to make any automatic DOM changes at all.		* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the parts of the page that are collaboratively edited, there is no reason for the UA to make any automatic DOM changes at all.

Aryeh Gregor: Update one requirement with a key clarification

2011-11-07T20:07:07Z

Update one requirement with a key clarification

← Older revision		Revision as of 20:07, 7 November 2011
Line 53:		Line 53:

	* The author must be able to decide exactly how undo/redo are executed if they so choose. They might want to use application-specific heuristics to undo changes when there are conflicts.		* The author must be able to decide exactly how undo/redo are executed if they so choose. They might want to use application-specific heuristics to undo changes when there are conflicts.
	* If browsers try to merge changes themselves, the algorithm ~~must~~ be well-defined. Otherwise it will just confuse authors and not be useful, because it will succeed in some browsers and fail in others, or have unpredictable results.		* If browsers try to merge changes themselves, the algorithm should be well-defined if possible. Otherwise it will just confuse authors and not be useful, because it will succeed in some browsers and fail in others, or have unpredictable results. However, this might be impossible to attain, because authors can always make DOM changes outside of any transaction, and thereby mess everything up.
	* It must be possible to have some parts of the page author-controlled, and some parts of the page UA-controlled. For instance, there might be a collaborative editor on the same page as some unrelated inputs.		* It must be possible to have some parts of the page author-controlled, and some parts of the page UA-controlled. For instance, there might be a collaborative editor on the same page as some unrelated inputs.
	* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the parts of the page that are collaboratively edited, there is no reason for the UA to make any automatic DOM changes at all.		* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the parts of the page that are collaboratively edited, there is no reason for the UA to make any automatic DOM changes at all.

Aryeh Gregor: More adjustment

2011-11-07T19:39:48Z

More adjustment

← Older revision		Revision as of 19:39, 7 November 2011
Line 43:		Line 43:
	* DOM state should still be controlled by the UA. Nothing in the use-case implies that the author wants to make any DOM changes that aren't undone/redone like any other DOM changes. The author must not be forced to deal with manually handling DOM state just because they want to handle non-DOM state.		* DOM state should still be controlled by the UA. Nothing in the use-case implies that the author wants to make any DOM changes that aren't undone/redone like any other DOM changes. The author must not be forced to deal with manually handling DOM state just because they want to handle non-DOM state.

	== ~~Full custom control of DOM state~~ ==		== Collaborative editing ==

	'''Scenarios:'''		'''Scenarios:'''
Line 49:		Line 49:
	* Real-time syncing of rich-text edited data with simultaneous multi-user editing. Data pulled in from other users should modify the DOM, but not be included in the undo history. When a user tries to undo something, it needs to undo only that user's changes, using some type of intelligent merge algorithm.		* Real-time syncing of rich-text edited data with simultaneous multi-user editing. Data pulled in from other users should modify the DOM, but not be included in the undo history. When a user tries to undo something, it needs to undo only that user's changes, using some type of intelligent merge algorithm.
	* Collaborative editing of non-rich-text things, such as canvas, as in the previous use-cases.		* Collaborative editing of non-rich-text things, such as canvas, as in the previous use-cases.
	* A slideshow app. There are multiple slides, each of which contains some editable content. The user is allowed to do rich-text editing on the slides using contenteditable, but also take other actions like adding or removing slides. There is UI that gives a list of slides, and some user actions will modify it (such as adding or removing a slide). However, some actions that are not tracked by undo/redo might also modify the UI, such as moving to the next or previous slide.

	'''Requirements:'''		'''Requirements:'''
Line 55:		Line 54:
	* The author must be able to decide exactly how undo/redo are executed if they so choose. They might want to use application-specific heuristics to undo changes when there are conflicts.		* The author must be able to decide exactly how undo/redo are executed if they so choose. They might want to use application-specific heuristics to undo changes when there are conflicts.
	* If browsers try to merge changes themselves, the algorithm must be well-defined. Otherwise it will just confuse authors and not be useful, because it will succeed in some browsers and fail in others, or have unpredictable results.		* If browsers try to merge changes themselves, the algorithm must be well-defined. Otherwise it will just confuse authors and not be useful, because it will succeed in some browsers and fail in others, or have unpredictable results.
	* It must be possible to have some parts of the page author-controlled, and some parts of the page UA-controlled. For instance, there might be a collaborative editor on the same page as some unrelated inputs~~. Likewise for the slideshow app~~.		* It must be possible to have some parts of the page author-controlled, and some parts of the page UA-controlled. For instance, there might be a collaborative editor on the same page as some unrelated inputs.
	* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the parts of the page that are collaboratively edited, there is no reason for the UA to make any automatic DOM changes at all.		* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the parts of the page that are collaboratively edited, there is no reason for the UA to make any automatic DOM changes at all.

			== Author-managed UI ==

			'''Scenarios:'''

			* A standard rich-text editor with various buttons and drop-downs. Undo/redo should not automatically affect any of the UI's state. E.g., if the user selects "red" in the color drop-down, undo should not change it back to the previous selection.
			* A slideshow app. There are multiple slides, each of which contains some editable content. The user is allowed to do rich-text editing on the slides using contenteditable, but also take other actions like adding or removing slides. There is UI that gives a list of slides, and some user actions will modify it (such as adding or removing a slide). However, some actions that are not tracked by undo/redo might also modify the UI, such as moving to the next or previous slide.

			'''Requirements:'''

			* The browser must not touch the UI parts of the page, but still has to fully manage the non-UI parts.
			* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the UI parts of the page, there is no reason for the UA to make any automatic DOM changes at all.

Aryeh Gregor: Refine one of the use-cases

2011-11-07T19:33:42Z

Refine one of the use-cases

← Older revision		Revision as of 19:33, 7 November 2011
Line 11:		Line 11:

	* A site wants to allow adding a special type of site-specific markup, say <span class=foo>.		* A site wants to allow adding a special type of site-specific markup, say <span class=foo>.
	* A slideshow app. There are multiple slides, each of which contains some editable content. The user is allowed to do rich-text editing on the slides using contenteditable, but also take other actions like adding or removing slides. All changes are either in the DOM, or could be stored in the DOM (using data-* or such).
	* A rich text editor provides a source code view that lets users edit HTML directly. In such an app, going to a source code view, edit HTML, and coming back to WYSIWYG view should be treated as one editing operation.		* A rich text editor provides a source code view that lets users edit HTML directly. In such an app, going to a source code view, edit HTML, and coming back to WYSIWYG view should be treated as one editing operation.
	* A code editor that implements auto-completion should be able to use user agent's undo transaction history.		* A code editor that implements auto-completion should be able to use user agent's undo transaction history.
Line 44:		Line 43:
	* DOM state should still be controlled by the UA. Nothing in the use-case implies that the author wants to make any DOM changes that aren't undone/redone like any other DOM changes. The author must not be forced to deal with manually handling DOM state just because they want to handle non-DOM state.		* DOM state should still be controlled by the UA. Nothing in the use-case implies that the author wants to make any DOM changes that aren't undone/redone like any other DOM changes. The author must not be forced to deal with manually handling DOM state just because they want to handle non-DOM state.

	== ~~Custom~~ control of DOM state ==		== Full custom control of DOM state ==

	'''Scenarios:'''		'''Scenarios:'''
Line 50:		Line 49:
	* Real-time syncing of rich-text edited data with simultaneous multi-user editing. Data pulled in from other users should modify the DOM, but not be included in the undo history. When a user tries to undo something, it needs to undo only that user's changes, using some type of intelligent merge algorithm.		* Real-time syncing of rich-text edited data with simultaneous multi-user editing. Data pulled in from other users should modify the DOM, but not be included in the undo history. When a user tries to undo something, it needs to undo only that user's changes, using some type of intelligent merge algorithm.
	* Collaborative editing of non-rich-text things, such as canvas, as in the previous use-cases.		* Collaborative editing of non-rich-text things, such as canvas, as in the previous use-cases.
			* A slideshow app. There are multiple slides, each of which contains some editable content. The user is allowed to do rich-text editing on the slides using contenteditable, but also take other actions like adding or removing slides. There is UI that gives a list of slides, and some user actions will modify it (such as adding or removing a slide). However, some actions that are not tracked by undo/redo might also modify the UI, such as moving to the next or previous slide.

	'''Requirements:'''		'''Requirements:'''
Line 55:		Line 55:
	* The author must be able to decide exactly how undo/redo are executed if they so choose. They might want to use application-specific heuristics to undo changes when there are conflicts.		* The author must be able to decide exactly how undo/redo are executed if they so choose. They might want to use application-specific heuristics to undo changes when there are conflicts.
	* If browsers try to merge changes themselves, the algorithm must be well-defined. Otherwise it will just confuse authors and not be useful, because it will succeed in some browsers and fail in others, or have unpredictable results.		* If browsers try to merge changes themselves, the algorithm must be well-defined. Otherwise it will just confuse authors and not be useful, because it will succeed in some browsers and fail in others, or have unpredictable results.
	* It must be possible to have some parts of the page author-controlled, and some parts of the page UA-controlled. For instance, there might be a collaborative editor on the same page as some unrelated inputs.		* It must be possible to have some parts of the page author-controlled, and some parts of the page UA-controlled. For instance, there might be a collaborative editor on the same page as some unrelated inputs. Likewise for the slideshow app.
	* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the parts of the page that are collaboratively edited, there is no reason for the UA to make any automatic DOM changes at all.		* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the parts of the page that are collaboratively edited, there is no reason for the UA to make any automatic DOM changes at all.

Aryeh Gregor: Complete an unfinished sentence

2011-11-07T19:27:31Z

Complete an unfinished sentence

← Older revision		Revision as of 19:27, 7 November 2011
Line 4:		Line 4:

	* Try to make every use-case as easy as possible to deal with. Don't make the common use-cases harder for the sake of allowing rarer use-cases.		* Try to make every use-case as easy as possible to deal with. Don't make the common use-cases harder for the sake of allowing rarer use-cases.
	* Don't allow any functionality that		* Don't allow any functionality that isn't required by a use-case. This adds complexity for no clear reason. If a use-case we didn't think of comes up later, add new functionality then, when we know exactly what we're looking for.

	== Managing DOM changes ==		== Managing DOM changes ==

Aryeh Gregor: Create page

2011-11-07T19:21:32Z

Create page

New page

Use-cases from [http://rniwa.com/editing/undomanager-usecases.html rniwa's page] and [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-October/033630.html a whatwg thread], patterned after [[Microdata Problem Descriptions]].

General principles:

* Try to make every use-case as easy as possible to deal with. Don't make the common use-cases harder for the sake of allowing rarer use-cases.
* Don't allow any functionality that

== Managing DOM changes ==

'''Scenarios:'''

* A site wants to allow adding a special type of site-specific markup, say <span class=foo>.
* A slideshow app. There are multiple slides, each of which contains some editable content. The user is allowed to do rich-text editing on the slides using contenteditable, but also take other actions like adding or removing slides. All changes are either in the DOM, or could be stored in the DOM (using data-* or such).
* A rich text editor provides a source code view that lets users edit HTML directly. In such an app, going to a source code view, edit HTML, and coming back to WYSIWYG view should be treated as one editing operation.
* A code editor that implements auto-completion should be able to use user agent's undo transaction history.

'''Requirements:'''

* It must be possible to associate a set of DOM changes with a custom entry in the undo history. The changes might be to non-editable areas.
* The author must have control over exactly what appears in the undo history. It must be possible to have multiple different DOM changes be one undo history entry, or multiple ones, with customizable labels.
* The author should have to do no special work to undo the action. The UA should track and undo the DOM changes just like for any command.
* Nothing in these use-cases requires that the author be able to specify any special action to be taken on undo/redo. All relevant state is in the DOM, or could be put in the DOM, so the UA can automatically handle undo/redo.

== Separate undo histories ==

'''Scenarios:'''

* A rich text editor has a widget to draw a vector-based illustration. The user should be able to open the widget and modify the illustration while leaving the undo transaction history of the main editor intact.

'''Requirements:'''

* The undo history for the vector image must not be intermixed with the undo history for the rest of the page.

== Non-DOM state ==

'''Scenarios:'''

* A canvas-based drawing app that uses server-side storage. Such an application should provide undo and redo menu items on the user agent's native UI.

'''Requirements:'''

* It must be possible for the author to track non-DOM state (such as canvas operations) in addition to just DOM state.
* It must be possible for the author to run arbitrary JavaScript, such as XHR, on apply/unapply/reapply of a transaction.
* DOM state should still be controlled by the UA. Nothing in the use-case implies that the author wants to make any DOM changes that aren't undone/redone like any other DOM changes. The author must not be forced to deal with manually handling DOM state just because they want to handle non-DOM state.

== Custom control of DOM state ==

'''Scenarios:'''

* Real-time syncing of rich-text edited data with simultaneous multi-user editing. Data pulled in from other users should modify the DOM, but not be included in the undo history. When a user tries to undo something, it needs to undo only that user's changes, using some type of intelligent merge algorithm.
* Collaborative editing of non-rich-text things, such as canvas, as in the previous use-cases.

'''Requirements:'''

* The author must be able to decide exactly how undo/redo are executed if they so choose. They might want to use application-specific heuristics to undo changes when there are conflicts.
* If browsers try to merge changes themselves, the algorithm must be well-defined. Otherwise it will just confuse authors and not be useful, because it will succeed in some browsers and fail in others, or have unpredictable results.
* It must be possible to have some parts of the page author-controlled, and some parts of the page UA-controlled. For instance, there might be a collaborative editor on the same page as some unrelated inputs.
* Nothing in the use-case requires that changes to any one node be tracked by both the UA and the author. In the parts of the page that are collaboratively edited, there is no reason for the UA to make any automatic DOM changes at all.