Re: [w3c/editing] [beforeinput] PreventDefault() on InputType=cut differs from Clipboard API (#144)

> I was arguing for having preventDefault stop the clipboard operations at the F2F, but choniong's proposal in https://github.com/w3c/editing/issues/144#issuecomment-240558462 seems like a more elegant solution to me. It gets rid of the expectation that the beforeInput even controls the clipboard access and focuses on just the DOM modification part of it, which seems desirable to me.

ok. If we can agree on this here, and then take the remaining issues for JS editors in the clipboard API, I think that should work.

> I wonder if a similar logic would apply to undo/redo, i.e. make preventDefault not prevent the items from getting popped from the undo stack? The complicated thing there is coming up with the name since undo/redo can both do deletes and insert. undoModification and redoModification maybe? That's wordy, but I think it at least would make it clear that the event is for the DOM modification, not the other parts of the user action.

So far, undo doesn't tell us what it wants to change at all (no target ranges). The issue here is also that if we do any editing at all in JS space, we end up not being able to use the browser's undo stack. So the question is then: Under what circumstances will someone create a JS editor that listens to the beforeinput event but never modifies the DOM by means of JS?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/144#issuecomment-240960783