- From: Ben Peters <Ben.Peters@microsoft.com>
- Date: Mon, 8 Dec 2014 18:15:53 +0000
- To: Koji Ishii <kojiishi@gmail.com>, Johannes Wilm <johannes@fiduswriter.org>
- CC: Olivier Forget <teleclimber@gmail.com>, public-editing-tf <public-editing-tf@w3.org>
On Mon, Dec 8, 2014 at 9:50 AM, Koji Ishii <kojiishi@gmail.com> wrote:
> On Sun, Dec 7, 2014 at 5:55 PM, Johannes Wilm <johannes@fiduswriter.org> wrote:
>> The first post there mentions two issues related to carets. Subsequently we
>> have then discussed one of those issues. If we had a specific document to
>> only talk about carets, then that's probably where those two posts would go.
>>
>> Or where else would you suggest for this to go?
>
> Just replied to Olivier in the split thread, but in principle, I'd
> like to split "move and set carets/selections" and "adjust for editing
> and typing". Even for horizontal move, moving caret to the next
> character isn't easy when i18n is taken into account, and there are
> lots of unknowns and possible innovations even for browser developers.
> I'm scared how long writing such spec would take, and also scared of
> the efforts to keep it updated.
>
> All that bother both browser and editor developers are the unspecified
> magic between carets were moved/set and carets are displayed, no?
Looks like we may need a new spec for this. We should decide if this is separate from Selection API or part of it.
>> Well, there are many other options of course, those just examples. Under 1,
>> they would be thrown out and removed entirely without replacement. It was
>> from my impression at the web summit that the browser people felt that
>> contenteditable=true would stay around additionally to
>> contenteditable=minimal for a good while because they believed many legacy
>> systems depend on it.
>
> Yeah, I guess so.
Correct, there is too much dependence on contentEditable='true' to remove it. With contentEditable="typing" we get a fresh start without breaking existing sites.
> 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.
Received on Monday, 8 December 2014 18:16:22 UTC