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

Reply via email to