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

> ### 1)
> 
> ```
> the suffix -esque, as in pictur<u>esqu|</u>
> ```
> 
> Autocomplete "picturesque" in Chrome, or typing "e" in Firefox Android will result in:
> 
> ```
> the suffix -esque, as in <u>picturesque</u>
> ```
> 
> ruining our intended styling.

Oh, really? This is terrible result... I guess that your IME selects the word and replace it. I mean that this is probably depends on IME. If the `<u>` has `compositionborder="true"` as your proposal, it's nightmare for web browser developers... (perhaps, hiding outside `compositionborder` contents from IME is the solution.)

> ### 2)
> 
> In a code editor, the same might occur with:
> 
> ```
> <var>let</var> x = <var>shor</var>-<var>ter|</var>
> ```
> 
> The browser does not know that we're dealing with programming code, and so thinks `shor-ter` is a single word/phrase that should be composed together with the IME.

It's a job of IME that which characters are treated as word separator. Browsers let IME know surrounding text as plaintext.

> This particular example can be observed in CodeMirror when editing on Android; when typing `this-some_var`, syntax highlighting is not properly applied until after composition finishes.

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.

> ### 3)
> 
> ```
> <b>some text </b><u>|</u>
> ```
> 
> Typing "here" will result in
> 
> ```
> <b>some text here|</b><u></u>
> ```
> 
> The browser treats the contents as one style-agnostic text phrase, ignoring that the cursor is inside `<u>` and retargeting it to `<b>` instead. While normal input events we can cancel and retarget it back to `<u>`, with composition events we can't edit the DOM until after composition has completed; and by that point, it is too late, since the text has already been styled bold.

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.

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

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

Received on Monday, 12 December 2022 08:52:09 UTC