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

I'd like to note that there were very similar discussion on CSS Writing Modes spec. Most native speakers prefers logical, while non-native tends to prefer physical. I'd like to explain how it went for your references.

What CSS WG ended up with is to go with physical, but there's one catch you should keep in mind. There are two kinds of direction; one you can interpret either physical or logical, and the other you cannot. In CSS, 'margin-top' can be interpreted in either physical or logical, while 'text-align: left' cannot align text to visual left because then it's no longer a function to align text within lines.

So what CSS WG defined these are:
1. For properties that can be interpreted either way, use physical (visual) directions
2. For properties that are line-oriented, we define 'line-left' and 'line-right' as in the table in the spec[1] and use line-relative mappings[2]

In this case, you're trying to define behavior for:
  modify('move', 'left/right', 'character')
So you have a choice between:
1. Make left/right as line-left/right as in the table[1], or
2. Change the meaning of 'character' to 'line'
Because there's no sense to move left/right by 'character' in vertical text flow.

I'd suggest option 1, since it's the option CSS WG agreed with, and changing 'character' to 'line' has far larger impact than changing 'left/right' to logical. 'character' and 'line' are two different models. For instance, 'line' does not have bidi reordering. You can't select a single character when text-orientation: sideways-left[3] (see the figure below the definition.)

If there were good enough use cases for physical directions, you could add:
  modify('move', 'left/right', 'physical')
but I'd suggest not to change the meaning of 'character'.

[1] http://dev.w3.org/csswg/css3-writing-modes/#logical-to-physical
[2] http://dev.w3.org/csswg/css3-writing-modes/#line-mappings
[3] http://dev.w3.org/csswg/css3-writing-modes/#text-orientation

Regards,
Koji

-----Original Message-----
From: whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Daniel Danilatos
Sent: Wednesday, June 29, 2011 2:37 PM
To: Ojan Vafai
Cc: Alexey Proskuryakov; Ryosuke Niwa; Koji Ishii; Ehsan Akhgari; whatwg at lists.whatwg.org; Boris Zbarsky; Aryeh Gregor
Subject: Re: [whatwg] getSelection().modify() in vertical writing modes

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
>

Received on Tuesday, 28 June 2011 23:08:36 UTC