- From: Ben Peters <Ben.Peters@microsoft.com>
- Date: Mon, 8 Dec 2014 18:45:17 +0000
- To: Olivier Forget <teleclimber@gmail.com>, Koji Ishii <kojiishi@gmail.com>
- CC: Johannes Wilm <johannes@fiduswriter.org>, public-editing-tf <public-editing-tf@w3.org>
On Sat, Dec 6, 2014 at 7:10 PM, Olivier Forget <teleclimber@gmail.com> wrote: > Right, I think we'd be trying to change that pattern. The problem is the UA > finally decides where text goes at the last step. I would prefer to see: > 1. User clicks on content > 2. document position is fully resolved by UA > 3. if that document position is editable, show caret, if not (user clicked > on an image or in cE=false) then don't > 4. if there is a caret, then getSelection returns that exact position where > text will be inserted if user types at that moment. > > What I'm saying is that the UA would need to maintain a one-to-one relation > between the following things: > - a blinking caret > - a fully resolved unique position in the document > - getSelection returns that exact position > - user's typing inserts text at said position > > If for whatever reason selection is at a non-editable position, then there > is no caret, and there is no insertion of text upon typing. > > This implies we need to spec a number of things: > - what's editable and what's not? > - where can text be inserted? (and how? can UA create text nodes?) > - how to resolve 1-visible:n-document positions > - caret movement via arrow keys as selection goes inside/outside elements, > and around non-editable elements This is a great start to a list. 1 and 2 should be in contentEditable. I filed https://github.com/w3c/editing-explainer/issues/21 for 2. 3 and 4 should be in Selection API or related. I'll start a thread for this.
Received on Monday, 8 December 2014 18:45:46 UTC