- From: Daniel Danilatos <daniel@danilatos.com>
- Date: Wed, 29 Jun 2011 15:36:45 +1000
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 22:36:45 UTC