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

[Glenn Maynard]

On Sun, Jan 30, 2011 at 6:18 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Sun, 30 Jan 2011, Aryeh Gregor 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.
>
> I think leaving it undefined is fine so long as the behaviour is
> consistent, e.g. that the boundaries used for text-transform:capitalize
> match the boundaries used for word boundaries in Selection.modify(). This
> may need some coordination work so that the specs use terminology that is
> unambiguously referring to equivalent concepts, without precluding that
> Selection be implemented in non-CSS UAs.
>

If this is meant to mimic keyboard selection, that doesn't necessarily
correspond to sane behavior for anything else.  For example, in Windows,
control-shift-right over "John's" in an input box selects up to the
apostrophe, not including the "s".  By comparison, if
"text-transform:uppercase-first-word" was implemented, it should probably
always capitalize "JOHN'S", regardless of how selection works on the
platform.

It's also worth pointing out that, at least in Firefox in Windows, there are
different modes of word selection.  If I double-click and drag to select
text over "John's", the apostrophe is excluded, where it's included with
keyboard navigation.

-- 
Glenn Maynard