RE: Manageable and predictable text insertion

Oh I see where I was confused. There has been some discussion about only having one new contentEditable. The way to prevent certain behavior would be to call preventDefault() on the Intentions you don’t want the browser to handle. In this case you want the browser to do Insertion, but not deletion, which doesn’t work with a single Intention like Replace. So either you want to be able to say contentEditable=”insertCharacters” which means no deletion, or you want two separate events that you can preventDefault() separately. Correct?

From: Olivier Forget [mailto:teleclimber@gmail.com]
Sent: Wednesday, November 12, 2014 5:50 PM
To: Ben Peters
Cc: Piotr Koszuliński; public-editing-tf@w3.org
Subject: Re: Manageable and predictable text insertion

On Wed, Nov 12, 2014 at 2:31 PM, Ben Peters <Ben.Peters@microsoft.com<mailto:Ben.Peters@microsoft.com>> wrote:
What do you think of the Replace idea in http://lists.w3.org/Archives/Public/public-editing-tf/2014Nov/0031.html ?


I think that under cE=insertCharacters, the Replace Intent should never trigger deletion of any nodes or elements.

According to your example you say:
    browser replaces the now-empty selection with "a"

In other words if the event is allowed to continue and the selection is non-empty the browser takes it upon itself to delete some stuff. This goes against my reasoning for cE=insertCharacters.

Simply put I really don't want the browser to ever touch the DOM Elements inside my editor. When the browser does that, my editor will be put in an uncertain state.

With cE=insertCharacters defined as I did, there is no possible confusion: a browser should not delete anything. Ever. This creates an environment in which I actually stand a chance of creating a decent editor that won't spring up random bugs.