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

@johanneswilm that makes sense about word boundaries. But I think the difference for me is that there's a distinction between how the spellcheck recognizes words, and how it treats existing markup when "fixing" the words. In my mind, there's nothing stopping them from recognizing words across inline elements, but still "fixing" the errors without changing the structure of those inline elements.

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

Right, right. I'm not talking about the actual events that fire. What I'm trying to point out is that it's ridiculous that browsers are editing the actual markup, instead of just changing the text nodes in response to these `beforeinput` events.

I don't understand why:

```html
<strong>fi</strong>ssh
```

Would **ever** turn into:

```html
<b>fish</b>
```

Or even:

```html
<strong>fish</strong>
```

When it could just as easily be kept intact as:

```html
<strong>fi</strong>sh
```

While still applying the "fix" for the spelling.

I'm not arguing against the existing spec for `beforeinput` at all, I think those are great. It's just the actual DOM mutations that browsers are performing for their native handling of these `beforeinput` events that makes no sense, and makes it a huge pain in the ass for JavaScript editors to deal with the aftermaths.

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