- From: Ben Peters <Ben.Peters@microsoft.com>
- Date: Fri, 13 Jun 2014 18:37:48 +0000
- To: Ryosuke Niwa <rniwa@apple.com>, Olivier F <teleclimber@gmail.com>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
On Fri, Jun 13, 2014 at 1:01 AM, Ryosuke Niwa <rniwa@apple.com> wrote: >> On Jun 12, 2014, at 5:07 PM, Olivier F <teleclimber@gmail.com> wrote: >> >> I have been reading this and have a comment: >> http://w3c.github.io/editing-explainer/commands-explainer.html >> >> "Issue 11: We may not need contentEditable=minimal. The same thing can be accomplished by listening for commands and calling preventDefault on all of them." >> >> I think we need contentEditable=minimal even if it is theoretically possible to listen to all commands and preventDefault on them. >> >> Listening to all events and preventing their defaults has the following implications: >> - All CommandEvents and other things that can modify the state of the contents in our cE actually do fire events. >> - We are actually able to enumerate all events that could potentially modify the state of our contentEditable. >> - All of these events can be preventDefaulted. >> >> Given the transient nature of specs, implementations, and bugs I have a hard time believing that the theory that we can just listen to everything and prevent defaults has merit in practice. >> >> One can easily imagine that some features provided by the UA won't fire events. Or, no need to imagine: just look at "undo" called from context menu. The goal of Commands is to allow sites to get a CommandEvent with type "undo" for just this scenario. >> Imagine as well a situation where a UA creates a new way to paste content, and to prevent confusion with "paste" they decide to create a new ua-prefixed event "uaMagicPaste". Now our end-users have a way of pasting content into our editor's DOM without any intervention at all on our end, resulting in breakage and bugs. This is a good point. Registering for and calling preventDefault() on CommandEvent and BeforeSelectionChangeEvent will catch all new events in those categories, but ClipboardEvents must be listened to individually (Cut, Copy, Paste). We should consider whether we disallow new ClipboardEvent types or allow a generic ClipboardEvent listener, which would catch uaMagicPaste. I'll add a note to the Explainer for this. >> In practice, if we are left with the burden of listening to all events and preventing defaults we are left in very much the same situation we're trying to get away from. >> >> >I don't have a strong opinion either way. However, can't you just whitelist the list of commands you allow and cancel everything else instead for this specific case? I guess you're concerned that it'll make things worse in some cases (e.g. new builtin browser features maybe disabled)? >- R. Niwa Ryosuke's idea here is the same as mine. Listen for CommandEvent, BeforeSelectionChangeEvent, and ClipboardEvent (if that becomes possible), and preventDefault() on them. That will block all current and future functionality that is provided by contentEditable.
Received on Friday, 13 June 2014 18:38:24 UTC