[whatwg] getSelection().modify() in vertical writing modes

[Daniel Danilatos]

My two cents, take it or leave it:

These specs and implementations are still quite immature and it's fine
to change their meaning slightly. So many things keep
breaking/changing anyway in the world of editing in practice anyway,
that there's not much point pretending to maintain backwards
compatibility especially for very new/immature features.

Up/Down/Left/Right should be visual directions, Forward/Back, with the
appropriate granularity, logical directions. This is kind of similar
to the whole idea of 'user intent' events - in some cases, I want to
know if the user wants to "paste", so I should get this event
regardless of whether they hit edit paste, ctrl+v, apple+v on a mac,
or with a custom key binding, etc. On the other hand, sometimes I just
want to know what key was pressed, with what modifiers, maybe I'm
implementing custom hotkeys or something, so then I want Ctrl+V as an
event. In the same vein, I want to know both what the "low level"
action was, i.e. did the user want to go visually left/right, and what
the "logical" action was, should we go forward or backward. I know
we're not necessarily talking about events, but the same applies to
modifying selections.

(Side topic: why are these capabilities on selections at all? Seems
like we're conflating two use cases. I might want to comprehend a word
boundary or a line boundary in my app logic, without touching the
selection. Seems like all this should be methods on text regions or
something like that, which could then in some scenarios be used to
modify the selection).

Dan


On Tue, Jun 28, 2011 at 8:33 AM, Ojan Vafai <ojan at chromium.org> wrote:
> On Mon, Jun 27, 2011 at 2:39 PM, Alexey Proskuryakov <ap at webkit.org> wrote:
>
>> 27.06.2011, в 14:30, Ryosuke Niwa написал(а):
>>
>> FYI, I also posted this question on public-html-ig-jp at w3.org, and I got
>> exactly one response from Koji, who was supportive of my proposal.
>>
>> Given that, I'm inclined to say that the consensus is to modify('move',
>> 'left'/'right', 'character') should move the caret in the direction of
>> line-left and line-right and modify('move', 'left'/'right', 'line') should
>> move the caret in the block direction (left for backward direction and right
>> for forward direction).  As Koji mentioned, it matches native-speaker's
>> intuition and it matches the concept of left/right in text-align property.
>>
>> I do not think that we should ignore people who are not native speakers and
>> are writing JavaScript code that works with vertical text. For most people,
>> left is left, and up is up. There is no reason to make it more complicated
>> than it is already.
>>
>
> There is no up! There's left, right, forward and backward. To do "up" in
> horizontal text you change the granularity from 'character' to 'line'. But
> you still use 'left' and 'right'. Keeping it so that 'character' selects a
> character and 'line' selects a line seems like the only choice here. We're
> not actually redefining what left/right mean any more than the current API
> already does by having left+line mean up. It's logical left instead of
> visual left.
>
> Ojan
>