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

[Silvia Pfeiffer]

In WebVTT we used "start" and "end" instead of "left" and "right".
Might that help?

Silvia.

On Tue, Jun 21, 2011 at 11:00 AM, 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
>