Re: [w3c/editing] Proposal: compositionborder attribute (Issue #414)

> it's nightmare for web browser developers... (perhaps, hiding outside compositionborder contents from IME is the solution.)

In Firefox, using `<article>` as the tag for styling text will emulate `compositionborder=true` behavior (at least tested in Firefox mobile with Android IME). So I figured there must be some kind of logic already in there that `compositionborder` could expose. But I'm not a browser developer, so I'll defer to your judgement there.

For example:

```
<span class='u'>te</span><span class='b'>ex|</span>
```
Will suggest "text" for autocomplete, but switching to `<article>` will suggest "exactly" for autocomplete instead. (I only see this behavior in Firefox)

> I guess that CodeMirror just touches the DOM tree after committing composition. That's the safest way. Updating the DOM tree will be notified IME. Then, IME may stop the composition, i.e., the behavior becomes depending on IME. That must be a nightmare for web developers.

In my tests, you cannot modify the DOM during composition. Chrome will allow it, but the IME (as tested in Android) does a janky refresh if you do a DOM modification. Firefox will silently proceed, but has some weird behavior where the remaining composition events are all fired incorrectly on orphaned nodes.

I suppose that was one of the stipulations of the Input Events Lvl 2 spec: all events could be prevented (e.g. you can manually handle DOM edits), *except* for composition events, which you must wait to complete before doing any DOM repairs. (If you could do preventDefault on composition events then that would solve everything, no need for `compositionborder` or other; though I've been told that Chrome has made it clear they cannot implement preventDefault for composition).

In any case, modifying the DOM during composition without preventDefault would be problematic, since the browser might restyle/add/delete nodes based on whatever internal DOM editing logic it has. You'd be constantly fighting to repair the DOM. Which is sort of the idea behind `compositionborder`: setting a border for the text editing range to tell the browser "hey, don't modify anything outside this range when you do the composition edit"

> I think that this should be fixed in each browser without any spec changes. Could be avoided with inserting empty text node there and collapse Selection into it.

Tested now and using a text node seems to work for Firefox, but Chrome still retargets to the `<b>` element. I'd support Firefox's behavior being standardized (and that would solve this case without needing `compositionborder`).



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

Message ID: <w3c/editing/issues/414/1347874728@github.com>