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

> I still think if you constrain the problem to only operation on text nodes you end up with a better solution here that editors are more likely to be able to work with.

I think most (all?) of us on the JS side of things tend to think that way, but at least last we checked, browser people thought differently about this and felt like they needed to check "partially styled words" like that. That we came up, as a working compromise, to have a cancelable before input event and a way to enable/disable spell checking for specific ranges and/or to have a way to communicate to the browser that certain element boundaries are to be regarded as word boundaries. For example in `<p>Hel<strong>lo</strong> Pet<img src="...">er!</p>" the first strong should maybe not be regarded as a word boundary, whereas the `<img>` could or could not be a word boundary depending a bit on how large the image is. 

Things may have changed now. It's interesting to hear @reinmar say that they do only check within text nodes. I wonder if that also is the case in IMEs on mobile, for example.

> If the browser decides it really needs to combine the letters under a single element, it can perform what amounts to a "remove" to erase `ssh` and an "insert" to insert `sh` into the `<strong>` element.

I think that's not really the best solution, as it doesn't tell the JS what the semantic purpose of those operations is. Maybe the JS decides it wants to ignore the spell checking entirely. Or it wants to show an animation in the case of spell checking fixes. Yet those operations don't really tell it what the user asked for.

Instead, it should create an atomic operation with a beforeinput event with the inputType set to "insertReplacementText". The target range should cover the entire range that the spell checking covers. That way the JS can cancel this beforeinput event and handle it exactly as it intended to do itself, figuring out how to deal with the strong element in there.


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