On Tue, Jun 17, 2014 at 2:39 AM, Julie Parent <jparent@google.com> wrote: > I certainly understand the concern that it would be impossible to properly > catch and cancel all events. > I'm not concerned only about this. I'm concerned about the fact that currently existing commands and editable-related features does not fit in a simple command APIs. > But I think that is somewhat the point - it forces browser vendors to get > these parts right. > The spec should guide engines' developers, because there's a single spec and many engines. Even if all browser vendors will get these parts right, they may choose different paths. And then, in general, this will be not right and it will be a pain for developers. > All changes to an editable dom must fire an event before the > modifications are made, and must be cancelable. Further, I'd say that if > the number of events you would need to preventDefault on grows larger than > selection, command, and maybe clipboard then that implies that we are not > building the right APIs. > > I don't think that number of events implies that we are building a bad API. Dozen of well defined events is better than three that do too much in an unclear way. Besides that, as an editor author I'm not only interested in preventing default action of features I don't want. I also want to hide them - remove them from browser UI like context menus, menu bar, or other widgets like special toolbar appearing over contenteditable on iOS. This makes the situation which spec has to describe much more complex. That's why I think it's better to focus on basics ( http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0918.html) than on trying to make specification for every feature that was introduced in any engine in any away. -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
Received on Tuesday, 17 June 2014 16:00:57 UTC