- From: Olivier F <teleclimber@gmail.com>
- Date: Thu, 12 Jun 2014 17:07:30 -0700
- To: public-webapps@w3.org
- Message-ID: <CAA5DY6Y3Nt6OU3DMajKFZyPyy=oT4s0NYnKfdyovN7bmzMELuw@mail.gmail.com>
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. If cE=min were spec'd to be an editable surface that had everything (or almost) off by default, including future features, then these kinds of surprises wouldn't happen. As developers we'd much rather implement new APIs when we feel we can, rather than having to scramble to preventDefault on new features when they appear on our end-user's browsers one morning. Thank-you for considering this. - Oliver Forget
Received on Friday, 13 June 2014 00:07:57 UTC