Re: [editing] CommandQuery Object and Event

On Jun 6, 2014, at 7:30 AM, Robin Berjon <robin@w3.org> wrote:

> On 06/06/2014 13:29 , Piotr Koszuliński wrote:
>> 1. That we need any native UI related to cE at all.
>> We don't. We can display our own toolbars, with our own buttons, with
>> our own icons and implementing our own logic. So the easiest solution to
>> the problem with irrelevant native UI is to not display it at all.
>> 
>> 2. That we need any native architecture for commands.
>> We don't. What a command is? It's a name, function and a state+value
>> refreshed on selection change. A command repository can be implemented
>> in JavaScript in few lines of code. CKEditor has one (and I guess that
>> all advanced editors have), because it is a necessary component on which
>> we must have full control. What it does, when it does, how a command is
>> executed, what arguments it accepts, which commands are available for
>> specific editor instance, etc.
> 
> FWIW I completely agree with Piotr. We need to be thinking about primitives that are as low-level as possible. We don't need to have any built-in support for things like bolding.

It's not a question of whether we need it or not. Browsers already DO have menu items to do it, and many users rely on that menu item working.

> If it somehow turns out that farther down the line there is a common set of commands that might somehow benefit from getting the native treatment we should cross that bridge then, but the v1 of this project should IMHO really, really not do more than what's needed for a script to cleanly implement an arbitrary text editor.

Things like undo, redo, paste, delete, select all, and "add link" in desktop Safari's edit menu, for example, need to work with whatever web app being developed.  It's not sufficient to provide UI within the web page.

- R. Niwa

Received on Friday, 6 June 2014 16:29:15 UTC