Be careful with having events fire before the DOM is updated—at a minimum you’ll want to consider whether you will allow dangerous situations like the legacy MutationEvents could cause (start a change -> pre-change notification -> make another change -> pre-change notification … unexpected things can happen (can be especially challenging to implement securely).
HTML5’s focus event model nicely prevents these recursions from looping. I’ve proposed a similar mitigation for the “beforeinput” event of DOM Level 3 Events: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25683 Seems like the Intention Events, if firing before the change is committed, might want a similar mitigation strategy. From: Ben Peters [mailto:ben.pet...@microsoft.com] Sent: Wednesday, May 28, 2014 1:40 PM To: Julie Parent Cc: public-webapps@w3.org Subject: RE: [editing] CommandEvent and contentEditable=minimal Explainer Great idea! If Intention Events (Clipboard, Selection, Command) cover all of the editing operations that a site would want to handle themselves, we don’t need CE Min as a feature, only a concept that can achieved with preventDefault(). From: Julie Parent [mailto:jpar...@gmail.com] Sent: Tuesday, May 27, 2014 4:40 PM To: Ben Peters Cc: public-webapps@w3.org<mailto:public-webapps@w3.org> Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer The discussion of which minimal default handling to include with contenteditable="minimal" makes me wonder if contentEditable="minimal" is necessary at all. It quickly becomes a can of worms of *which* default handling should be included, and it seems likely to not satisfy every use case no matter which decisions are made. However, "minimal" is proposed as a building block because currently, disabling all default functionality of contentEditable="true" is difficult/impossible. But with CommandEvents, shouldn't contentEditable="minimal" be equivalent to: // Let editRegion be <div contentEditable id='editRegion'> var editRegion = document.getElementById("editRegion"); editRegion.addEventListener("command", handleCommand); function handleCommand(evt){ evt.preventDefault(); } No default actions would be taken, but selection events would still fire and be handled. There would be no ambiguity. If implementing contentEditable="minimal" on top of CommandEvents could just be a few lines of code, why complicate things by spec'ing another property? Then, if someone wants a region that just does basic text input, then they simply allow it: function handleCommand(evt){ switch (evt.commandType){ case 'insertText': // Let the browser do text insertion break; default: // Prevent all other magic evt.preventDefault(); } This hedges on the fact that CommandEvents would capture ALL the cases that contentEditable currently handles, and that the event would fire BEFORE the dom is modified, and that calling preventDefault would cancel the event, but isn't that a goal of this design anyway? Julie ---------- Forwarded message ---------- From: Ben Peters <ben.pet...@microsoft.com<mailto:ben.pet...@microsoft.com>> Date: Thu, May 22, 2014 at 4:56 PM Subject: [editing] CommandEvent and contentEditable=minimal Explainer To: "public-webapps@w3.org<mailto:public-webapps@w3.org>" <public-webapps@w3.org<mailto:public-webapps@w3.org>> I have completed a first-draft explainer document [1], taking the generous feedback of many of you into account. There are 6 open issues on the document currently, and I'm sure there are others that I have missed. It would be great to know if this is heading in in the right direction. My vision is to use this a non-normative Explainer, and create 2 normative specs to go with it. The specs for contentEditable=minimal and CommandEvent should have first-drafts next week. Thanks! Ben [1] http://benjamp.github.io/commands-explainer.htm
