[whatwg] Spellcheck API (Re: selection.modify behavior across platforms)

[Hironori Bono (坊野 博典)]

Greetings,

Sorry for my off-the-topic e-mail.
I'm interested in spellcheck API these days because web-application
developers like to customize the behaviors of the spellchecker
integrated in Chrome or use it in their web applications. For example,
adding e-mail addresses in a contact list when typing an e-mail
address in a "To:" field, checking the text retrieved via
XMLHTTPRequest, etc. If there are those who already work for
spellcheck API, I would like to work with them. So, it would be great
to give me those who work for spellcheck API. (I wonder if all
browsers really need this API, though.)

Regards,

Hironori Bono
E-mail: hbono at google.com

On Mon, Mar 28, 2011 at 3:00 AM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> 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 . . .
>