- From: Koji Ishii <kojiishi@gmail.com>
- Date: Sat, 13 Dec 2014 13:39:03 +0900
- To: Ben Peters <Ben.Peters@microsoft.com>
- Cc: Johannes Wilm <johannes@fiduswriter.org>, Olivier Forget <teleclimber@gmail.com>, public-editing-tf <public-editing-tf@w3.org>
Thank you Ben for your reply.
On Tue, Dec 9, 2014 at 3:15 AM, Ben Peters <Ben.Peters@microsoft.com> wrote:
> On Mon, Dec 8, 2014 at 9:50 AM, Koji Ishii <kojiishi@gmail.com> wrote:
>
>> What about execCommand()? Do editor developers want it to work against
>> contenteditable=typing? Sorry if this was already discussed.
>
> Yes we have discussed this. So far we've said we want to leave execCommand attached to the legacy browser behavior. If a site wants to declare an Intention, they can use declareIntention. If they want to invoke legacy behavaior, they can call execCommand. Put another way:
>
> declareIntention('bold') -> fire beforeInput with intention="bold"
> beforeInput with intention="bold" in contentEditable="typing" has no default behavior
> execCommand('bold') -> invoke browser's non-standard non-interoperable bold behavior. DO NOT fire beforeInput.
Regarding the selection normalization, I believe, the idea is that
when selection is on contenteditable=typing, browsers do new behavior,
while otherwise legacy behavior.
Since execCommand() involves selection normalizations, making it to
work well against the new normalization behavior is not easy. I would
prefer execCommand() simply fails if the selection contains
contenteditable=typing, and editors do all the work with intentions
and possibly with DOM manipulations.
What do you think?
/koji
Received on Saturday, 13 December 2014 04:39:30 UTC