On Jun 15, 2011, at 4:14 PM, Ryosuke Niwa wrote:
> WebKit would like to support visual caret movements in vertical writing modes
> [1]. How should getSelection().modify() support this new behavior? In
> particular, what getSelection().modify('move'/'extend', 'left'/'right',
> 'character') should do?
>
> One possibility is that getSelection().modify('move'/'extend',
> 'left'/'right', 'character') will move caret visually left or right, thereby
> moving between lines in vertical writing mode. This way, the semantics of
> moving left and right is preserved. However, the semantics of moving by
> 'character' is lost. In this case, getSelection().modify('move'/'extend',
> 'left'/'right', 'line') should move caret visually up or down (moving one
> character at a time).
>
> Now, in horizontal writing modes, 'left' and 'right' are used to move caret
> in visual order (in the sense of bidirectional text) and 'forward' and
> 'backward' are used to move in logical order. However, swapping the meaning
> of 'character' and 'line' for 'forward' and 'backward' is quite confusing as
> they used to walk DOM in logical order, and didn't depend on how characters
> are presented.
>
> On the other hand, if we left modify() intact - i.e.
> getSelection().modify('move'/'extend', 'left'/'right', 'character') move
> caret in visual order (i.e. visually up or down) in vertical writing mode -
> then scripts need to manually detect whether the content in which the caret
> resides is in vertical writing mode or not and change granularity between
> 'character' and 'line' in order to emulate arrow key movements.
I think using a Selection object method to emulate arrows keys is strange.
Why not provide a general way to emulate the arrow keys if we think that's
useful–if the focused area is an editable document, then those events can
result in selection changes.
If we need a way to write tests for selection changes in vertical text in the
meantime, I think using forward/backward by character/line should be fine.
Justin
