Re: [editing] CommandEvent and contentEditable=minimal Explainer

But what is the "default" behaviour then? What will we be preventing?
There's no accepted specification for current contentEditable=true AFAIK,
so I thought that the goal of contentEditable=minimal is to avoid the need
to write a specification for contentEditable=true. Otherwise, developers
may demand from browser vendors that they fix their contentEditable=true
implementations and I don't think that anyone wants that. Why not forget
about contentEditable=true, make it deprecated and create specification
only for algorithms needed by contentEditable=minimal and all required
command events?


On Wed, May 28, 2014 at 10: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’t 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
>
>
>



-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer