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.

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.

I think this might also help address gked's concern at the F2F of us pouring too much into this API and other concerns about this becoming some catch-all event.

As to making it easier to putting things on the clipboard, I agree that the best way to handle that is to file an issue on the clipboard API.

We should not ad global opt-in/opt-outs IMO since they kill composability. That's one of the problems with the existing execCommands that change state that we should avoid.

-- 
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-240892363