Simpilified version of this API for the start

[NavidZ]

cc @whsieh @rniwa @mustaq @gked

I'm not sure where you prefer the issues to be filed. Against the explainer here or against the spec under Ryosuke's repo. Maybe if we just create one repo in WICG for this it might be more visible and clear for the folks. Feel free to contact one of the WICG owners (like @yoavweiss) for moving this under WICG. Anyhow, I'm filing one here and we can move the discussion anywhere we like later.

Following the comment from @johanneswilm comment during the breakout session that the rich editors are not going to give up their own undo manager stack (for different reasons like collaborative history effect that will always be there) and may be only using this API for the last two items, I was wondering whether we can start off with something like that.

Basically I wonder what happens if we remove the nested undo managers as well as letting the app to add/modify/see the whole list. What happens if we just expose that last undo/redo item and let the app set those. This would solve all those already existing rich editors as well as exposing setting the label or any other platform ui/text for those actions if available on the platform. Also per another comment in the session when changing language they don't need to go and change the whole list. But they just need update the single item for redo/undo with the new language maybe.

Obviously I haven't thought the format of such API but if we go with that we should definitely have it in a way that can be extended to what the current proposal exposes (mainly the nesting functionality and full history). So we can extend it when there is enough need for these extension.

I wonder what other's thoughts are about this.

[johanneswilm]

The last issue on this was filed here: https://github.com/w3c/editing/issues/209

On Wed, 18 Sep 2019, 19:51 Navid Zolghadr, notifications@github.com wrote:

cc @whsieh https://github.com/whsieh @rniwa https://github.com/rniwa @mustaq https://github.com/mustaq @gked https://github.com/gked

I'm not sure where you prefer the issues to be filed. Against the explainer here or against the spec under Ryosuke's repo. Maybe if we just create one repo in WICG for this it might be more visible and clear for the folks. Feel free to contact one of the WICG owners (like @yoavweiss https://github.com/yoavweiss) for moving this under WICG. Anyhow, I'm filing one here and we can move the discussion anywhere we like later.

Following the comment from @johanneswilm https://github.com/johanneswilm comment during the breakout session that the rich editors are not going to give up their own undo manager stack (for different reasons like collaborative history effect that will always be there) and may be only using this API for the last two items, I was wondering whether we can start off with something like that.

Basically I wonder what happens if we remove the nested undo managers as well as letting the app to add/modify/see the whole list. What happens if we just expose that last undo/redo item and let the app set those. This would solve all those already existing rich editors as well as exposing setting the label or any other platform ui/text for those actions if available on the platform. Also per another comment in the session when changing language they don't need to go and change the whole list. But they just need update the single item for redo/undo with the new language maybe.

Obviously I haven't thought the format of such API but if we go with that we should definitely have it in a way that can be extended to what the current proposal exposes (mainly the nesting functionality and full history). So we can extend it when there is enough need for these extension.

I wonder what other's thoughts are about this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/whsieh/UndoManager/issues/1?email_source=notifications&email_token=AAERMOCGFHXO35SJVCJKWY3QKIB3RA5CNFSM4IX5AG6KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HMDLTRQ, or mute the thread https://github.com/notifications/unsubscribe-auth/AAERMOH4VL6DAOIBMMIRNILQKIB3RANCNFSM4IX5AG6A .

[johanneswilm]

If "access to the last item" means that one can add and remove just exactly one item to the undo and redo stacks and that it's possible to specify that an element has an undo stack that is separate from the global undo stack, then I think that for richtext editing apps this would also work and possibly less awkward as one wouldn't have to add two items to the undo stack and undo one to enable both the undo and the redo button.

It may not be that great for other applications though - non-collaborative image editing for example which this spec seems to be aiming at. I am not sure if those applications would like to give up their own undo stack and let a browser based undo manager take over.

As for WICG: Because the aim of this spec is not just text editing---even though the discussion seems to be mainly about that aspect---I agree that the spec should go through the WICG system and linked to from the editing repository. Had the spec been only relevant to text editing, I would have argued that it would make more sense to put the draft into the editing repository together with other text editing related specs drafts.