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

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

Received on Monday, 20 June 2011 18:00:18 UTC