- From: Robin Berjon <robin@w3.org>
- Date: Mon, 23 Jun 2014 18:19:14 +0200
- To: Julie Parent <jparent@google.com>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>, public-editing-tf@w3.org
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
Received on Monday, 23 June 2014 16:19:25 UTC