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

> In simpler scenarios (and that's a really big percentage)

The problem is that if it's 99% simple text but there is just one slightly more complex element that gets messed up on just one of the browser/OS combinations, that already makes it quite unusabffdle. Or if the end user with her/his Grammarly subscription is able to edit social media comments on most platforms correctly, but that one day he/she needs to hand in a school essay it messes up the entire paper 5 minutes before the deadline, it's highly annoying.

I just tried Grammarly again for the first time in a few years. It seems to work in this issue, but in Gmail it just managed to delete an entire email I had typed already. That's not really helpful. What it does is it creates an element that overlays the existing textarea/CE with the same content but with marked ranges and then it hopes that this doesn't interfere with the JS app it's working on. This works in Github comments, but apparently doesn't always work in Gmail. 

However, server-based spell checking doesn't always make sense. Some pages may need to work while offline. And it doesn't really make sense to spend a lot of server resources on something that the browser can do already given that browsers OSes come bundled with spellcheckers.

So a combination of these things should be helpful in all cases:

* A way to mark ranges of text without having to add new elements. This should give Grammarly & co alternatives for adding their mark and prevent them from destroying web pages.

* A way to mark certain ranges of text as being in need of spell checking or having been spell checked already, without having to add new elements.

* Ideally: a way to access the OS/browser-based spellchecker. For security reasons this may be the dictionary as it was shipped with the browser/OS without custom entries made by the user.

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

Received on Thursday, 4 October 2018 11:33:56 UTC