- From: Koji Ishii <kojiishi@gmail.com>
- Date: Sat, 13 Dec 2014 13:53:02 +0900
- To: Olivier Forget <teleclimber@gmail.com>
- Cc: Johannes Wilm <johannes@fiduswriter.org>, Ben Peters <Ben.Peters@microsoft.com>, public-editing-tf <public-editing-tf@w3.org>
On Tue, Dec 9, 2014 at 4:33 AM, Olivier Forget <teleclimber@gmail.com> wrote: > > I don't quite agree with #2, at least how it's phrased. It depends on how > the process was started. It's more like this (in my view): > Entry via click: > 1. User clicks > 2. UA resolves document position. It may be that the user clicked on an > image, in which case it's not editable. If clicking in an editable area > there may be some ambiguities where there are 1:visible:n:document > positions. The spec clarifies the proper document position to use, and the > UA acts accordingly. > 3. if position is editable, set the selection and go to 4 below I would like to split #2 to: 2.A. UA determines the first candidate document position 2.B. Then normalize it to proper editable document position. and > Entry via arrow keys: > 1. User presses arrow key (note that for arrow keys to effect caret > movement, the caret must already be visible, ie: the selection must already > be editable) > 2. A new editable position is calculated. There could be ambiguities > regarding the correct position. The spec should clarify proper caret > movement. > 3. By definition the selection is editable, set selection, go to 4. and #2 of this to: 2.A. UA determines the first candidate document position 2.B. Then normalize it to proper editable document position. Then we'd get a common single algorithm for 2.B. As I said before, my preference is to do 2.B. outside the browsers, probably by a JavaScript library. >> and n could >> also be 0. > > Could you please give a specific example of 0-visible:1-editable? If you are > referring to the case of an editable element being hidden, we are leaning > heavily towards treating invisible elements as effectively non-editable. Right, if you agree to split #2 to #2.A and #2.B, the spec could say #2.A is UA dependent but browsers must assure that the candidate position must be visible. You're right that then #2.B no longer need to worry about 0-visible. The "visible" needs to be defined clearly though. /koji
Received on Saturday, 13 December 2014 04:53:28 UTC