Re: [editing] CommandEvent and contentEditable=minimal Explainer

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.Peters@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ft need CE Min as a feature, only a concept that can achieved with preventDefault().
>  
> From: Julie Parent [mailto:jparent@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.Peters@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
> 
>