On Mon, Dec 15, 2014 at 1:03 PM, Ben Peters <Ben.Peters@microsoft.com> wrote: > > What is the advantage of an API not working in cE=typing? If you don’t > want it to work on your site, just don’t call it. Am I missing something? > > > I don't mind if the API stays, but the cE=typing spec has to make it abundantly super clear that the UA should not execute any exec Commands by default. (Example Ctrl-B does not trigger the bold command, even if the intent event is not canceled.) On the flip side, we certainly don't want to spec the exact behavior of execCommand, so it will behave with its cE=true mentality, which is the antithesis of cE=typing. This could muddle the true purpose of cE=typing. Would it be better to neutralize execCommand so that editor devs get the message that they are intended to write their own commands? *From:* Frederico Knabben [mailto:f.knabben@cksource.com] > *Sent:* Monday, December 15, 2014 8:13 AM > *To:* Koji Ishii > *Cc:* Ben Peters; Johannes Wilm; Olivier Forget; public-editing-tf > *Subject:* Re: execCommand and contenteditable=typeing (was Re: Only Text > Input and Intention Events > > > > On Saturday, 13 December 2014 at 05:39, Koji Ishii wrote: > > I would > > prefer execCommand() simply fails if the selection contains > > contenteditable=typing, and editors do all the work with intentions > > and possibly with DOM manipulations. > > I couldn’t agree more. > > > > Do we want to make exceptions for some commands that don’t touch the DOM, > like execCommand(‘selectAll’)? Actually this may be the one and only case. > > > > I would be fine to totally dropping execCommand, for consistency. > > > > -- > > Frederico Knabben > > CKEditor Project Lead and CKSource Owner > > -- > CKSource - http://cksource.com > -- > Follow us on: Twitter <http://twitter.com/ckeditor> | Facebook > <http://www.facebook.com/ckeditor> | Google+ > <https://plus.google.com/107736718646302128806> | LinkedIn > <http://www.linkedin.com/company/cksource> > > > > >
Received on Monday, 15 December 2014 21:46:10 UTC