[whatwg] selection.modify behavior across platforms

[Aryeh Gregor]

On Sat, Mar 26, 2011 at 1:46 AM, Ehsan Akhgari <ehsan at mozilla.com> wrote:
> If we define selection.modify with granulatity set to "word" as extending the selection to the start/end of the current word (or for that matter, to the start/end of the next/previous word!) we would have a consistent result for calls on this API.  For example, if somebody is writing a spell correction UI, they would want to replace the currently selected word with another word.  Even if we choose the latter definition for the API (which I find less intuitive), the author knows that they need to deal with word separator characters separately.
>
> But with the behavior of the API changing based on the platform, the author can either choose to sniff the UA string, or check what the API did after calling it.  The scarier scenario is the author testing their application on one platform, and deploying it without realizing that it will break in other platforms.

Why would an author want to use Selection.modify() to implement a
spellcheck API?  Wouldn't that imply that they'd have to save the
user's selection somewhere, create a new one, modify() it to the right
place, do whatever they want to do with the resulting range, then
remove the ranges and restore the original selection?  Not only is
this complicated and easy to get wrong, it might result in the
selection visibly flickering.  For things like spellcheck, wouldn't we
want to have an API on Range instead?

If you're manipulating the selection, that suggests to me that you
should be doing it in order to change the visible selection for the
user's benefit.  If you're altering things for the sake of your own
scripts and not the user, you shouldn't be altering the selection, and
if you're forced to do that, that suggests the API is bad.  Similarly,
the only way right now to convert HTML to plaintext that works in all
browsers is to use Selection.toString() -- that's bad.

(I notice WebKit has a bug open for creating a Range.modify() method:
<https://bugs.webkit.org/show_bug.cgi?id=34821>.  They seem to have a
Range.expand() method that does something related to this:
<http://trac.webkit.org/changeset/48271>.)

On Sat, Mar 26, 2011 at 2:51 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> I'm not sure why we need to provide a consistent behavior all platforms.  I
> think the whole point of modify() function is so that scripts can emulate
> selection operations user can initiate.  Imagine an app that intercepts user
> actions such as key down and manually sets selection using modify() because
> it needs to update some internal state, etc... in such applications, it's
> extremely desirable that the result of modify() to match what user does.

Why can't such an application just return true from the event handler
to let the platform-specific behavior take effect?  Indeed, if it
wants to respect platform-specific behavior, it can't rely on calling
modify() in response to keypresses, because the same keypresses have
entirely different effects on different platforms.  For instance,
IIRC, Home on OS X goes to the beginning of the text field instead of
the beginning of the line as on Windows/typical Linux; Ctrl-A goes to
the beginning of the line instead of doing nothing special as on
Windows/typical Linux; etc.  Some of this stuff is even configurable
on some platforms (at least GTK, AFAICT).  So if the user presses
Home, how are you going to decide whether to modify() by
"lineboundary" or "documentboundary"?  The only reliable way is to not
interfere at all.

At this point I'm still really unclear on what the use-cases are for
this feature.  I wasn't able to find discussion in the WebKit bug
tracker in a quick search.  I also didn't find any explanation of
actual use-cases on the Mozilla bug:
<https://bugzilla.mozilla.org/show_bug.cgi?id=496275>.  I get the
impression there are actual use-cases for *something* resembling this
feature, I just haven't figured out what they are . . .