Re: [w3c/editing] spellching - how to give JS devs more control (#166)

I think that there are two cases here:

* the editor wants to perform spell checking itself (perhaps, with some aid from the browser),
* the editor wants to integrate well with the native spellchecker.

We've been avoiding the first scenario because it's really tricky. Taken today's limitations, the spell checking engine needs to be placed on the server side (Grammarly, WebSpellChecker) and then it needs to be integrated very well with the client side. The last part is especially problematic because one service needs to be integrated with various editors. It also requires custom UI as we're not able to control the native context menu well. So it's getting costly and messy. E.g. when I checked it in the past Grammarly was crashing Draft, Medium, ProseMirror (I think) and to some extent CKEditor 5 too. So, resolving this situation could be one thing. I guess that what everyone would like to see is a non-intrusive way to underline (with a squiggle) ranges of text. If that was possible without changing the DOM a lot of things would become much easier (e.g. custom IME implementations? ;))

The second scenario is what most of us choose – to integrate best with the native spell checker. For us (CKEditor 5) it means two things:

* Handling changes done by the spellchecker (`beforeinput`, I'm looking at you).
* Telling browser to ignore certain markup when tokenizing the text in a search for words. E.g. `wo<b>rd</b>` is two words for most browsers. Also, which is even more important in collaborative editing, `wo<span></span>rd` is also sometimes considered to be two words (and we need those spans to represent other users selections). It'd be great if we could mark those inline elements to be ignored by the browser's spell checker.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/166#issuecomment-311331999