[whatwg] Request for implementer feedback: granularity definitions for Selection.modify()

[Tim Down]

It seems to me like there's an additional complication: presumably
Selection.modify() acts on only the text that is visible to the user,
which lands you with the problem of first specifying what that text
is. This is similar to the problem presented by specifying the
toString() method of Selection (which needs revisiting: see
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10583), or the innerText
property of elements.

Tim

On 30 January 2011 21:33, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> I'm working on a definition of Selection.modify(), and have run into
> the problem of how to define the various granularities used there.
> (See <https://developer.mozilla.org/en/DOM/selection/modify> for basic
> docs.)  The intent of the API is clearly that, e.g.,
> selection.modify("move", "right", "character") should do something
> like hitting the right arrow key, selection.modify("extend", "right",
> "line") should be like Shift+Down, etc.  But this is platform-specific
> in practice -- e.g., Ctrl+Left and Ctrl+Right use different
> definitions of word boundaries in different programs I use.
>
> To what degree should I try to define how these granularities work?  I
> could go ahead and say that moving by characters should be done by
> moving to the next grapheme cluster boundary as defined by UAX#29, for
> example.  Or I could say that it should follow platform conventions
> for when the user advances by a character, e.g., using the right and
> left arrow keys.  Or maybe something else?  What would implementers
> prefer?
>
> In practice, in other places where this stuff is needed (like
> line-breaking or :first-letter), we just leave it entirely undefined,
> which doesn't seem ideal but perhaps isn't fully avoidable.
>