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

@gked What would `document.getElementById("elementId").spellCheckOff(startPos, endPos);` do? Disabled the native spell checker on the given range? I don't think it would be helpful in any way.

As I wrote in https://github.com/w3c/editing/issues/166#issuecomment-311331999, there are two scenarios that we need to handle:

1. Implementing a custom spell checker. That's done by companies like Grammarly and WebSpellChecker. They use `spellcheck=false` to disable the native spell checker globally for the entire editing host and then render some squiggles by adding `<span>`s do the DOM.

   The problem here is that you cannot easily integrate your spell checking engine with all (or most) rich text editor at once. Most modern rich text editors have an architecture which does not allow any other JS app to modify that editor's DOM. Modifying their DOM directly either have no effect (the editor reverts that) or crashes that editor. This is a case with Grammarly which had to be disabled in Medium, CKEditor 5, Draft, etc. 

   A solution to that would be if we were able to render squiggles or any other text decoration without actually touching the DOM. I call it "range decoration". I'm not sure how (and if) this can be implemented by browsers – i.e. how to make ranges controlled via CSS. Theoretically, this could work similarly to `::selection`, like this:

    ```js
    const rangeId = range.decorate();
    ```

    ```css
    ::range(rangeId) { 
       color: red;
    }
   ```

   Or one would be able to pass CSS props directly to `range.decorate()`:

   ```js
   range.decorate( 'color: red' );
   ```

   Anyway, such a feature would be a great help in dealing with many kinds of editing features. We could also use it to display (in real-time collaboration scenarios) selections of other users, markers for their comments, etc. without changing the DOM so without affecting IME or the native spellchecker (the blinking mentioned by @ianstormtaylor). Such a feature would also enable much greater composability of JS libraries. Grammarly or any other company would be able to build a spell checking solution for every rich text editor on the market without investing in plugins built for each of them.

2. The second scenario is where a text editor tries to integrate best with a native spell checker. Here, as I mentioned, we should be able to handle all changes done by the user with `beforeinput`. Let's say that's covered already.

   The other issue in this scenario is how the browser handles:
  
   * Some edge cases like `woo<b>rd</b>`, `woo<span>rd</span>` or `woo<span></span>rd`. Right now, many of them are not handled correctly – "woo" and "rd" are treated as two separate words.
   * What happens when the text editor updates the DOM. Right now, that makes the squiggles for misspelled words to blink. The CKEditor 5's rendering engine is designed to make absolute minimum DOM changes because we knew how fragile IME or spell checking are but I understand @ianstormtaylor's problems with blinking squiggles when React rerenders the DOM. OTOH, I think that there's little that we can spec here – it's mostly about how spell checking engines are implemented on the browsers side.

-- 
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-426966053