On 28/05/2014 01:39 , Julie Parent wrote:
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?

I like the simplicity of this approach, but I have some concerns.

As Travis points out, this implies that all events have to be cancellable in this context. This can lead to problems (like we had with mutations), it can also have performance implications.

Another aspect that may be problematic is the case of UAs that provide a UI (like Safari Mobile) whenever they see contentEditable. I was hoping that contentEditable=minimal would serve as a sanity flag not to include that. In the above it's not possible.

I am not sure that we can have this work properly without specifying the default behaviour, which as we all know is a terrible mess. If you don't have reliable default behaviour, can you really rely on the browser to DTRT for the cases you don't wish to handle? Won't you end up having to use a library anyway?

Again, I'm all for the simplicity; I'm just worried about the snoring dragon.

--
Robin Berjon - http://berjon.com/ - @robinberjon

Reply via email to