On 17/06/2014 02:39 , Julie Parent wrote:
I certainly understand the concern that it would be impossible to properly catch and cancel all events. But I think that is somewhat the point - it forces browser vendors to get these parts right. 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.
Apart from other problems with building on top of contentEditable=true (notably that you keep getting the native browser UI, which is likely very wrong) I'd be really worried that we'd be painting ourselves into a corner with this approach.
If we realise a year or two from now that the design we picked isn't ideal and that we'd really need a new event type, the reliance on "prevent everything I don't know about" could severely constrain our options, and force us to shoehorn new functionality into existing events just to make sure we don't break existing content.
I don't think that the (limited) benefits are really worth it. -- Robin Berjon - http://berjon.com/ - @robinberjon
