I agree it's better to let authors define what behavior they want from UA instead of defining the set of behaviors ourselves.
Furthermore, I'd argue that we should separately have a mode where scripts would get intention events but UA wouldn't enact any builtin editing commands as default actions. This is useful for non-text editing applications such as drawing and presentation apps. - R. Niwa > On May 28, 2014, at 1:39 PM, Ben Peters <ben.pet...@microsoft.com> wrote: > > 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 > 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> > Date: Thu, May 22, 2014 at 4:56 PM > Subject: [editing] CommandEvent and contentEditable=minimal Explainer > To: "public-webapps@w3.org" <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 > >
