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

[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.

- Ryosuke

On Mon, Jun 20, 2011 at 6:00 PM, Ojan Vafai <ojan at chromium.org> wrote:

> On Mon, Jun 20, 2011 at 5:33 PM, Alexey Proskuryakov <ap at webkit.org>wrote:
>
>> 15.06.2011, в 16:13, Ryosuke Niwa написал(а):
>>
>> > 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.
>>
>> I think that redefining "left" and "right" to mean something different
>> would be much more confusing in the long run. Just like we didn't redefine
>> "left" and "right" for RTL, I don't see why we need to do that for vertical
>> text.
>>
>
> I don't think we can make this decision based on comparisons to RTL. If we
> wanted this API to make sense, we'd disallow using "left" and "right" in
> vertical writing mode and require "up" and "down" instead. The downside is
> that web developers who use this will now need to consider vertical writing
> mode, which I expect very few developers will.
>
> I think we should try to make "left" and "right" do the what web developers
> would expect them to do in non-vertical writing mode. Specifically, they
> should select a single character if you pass "character" as the granularity
> and a single line if you pass "line" as the granularity. That way developers
> don't need to specially handle vertical writing mode for logic like "select
> the next character and do something with it".
>
> Realistically, we need to operate in a world where developers won't know to
> handle vertical text specially.
>
> Ojan
>