On Jun 12, 2014, at 5:07 PM, Olivier F <teleclim...@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. > > 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. > > 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
