Candidate lists usually float near the caret and easily cover the text being edited

What it is

During pinyin or zhuyin composition, the candidate list often floats next to the caret so the eye can sweep from the text to the words. Nearness costs covering already-committed characters around the caret, the previous line of context, or the source being copied. People trying to check “was that last word this one” cannot see that last word. What is occluded is the text under edit, not the soft keyboard at the bottom, and not which item the ranker placed first.

Why it happens

The window is typically anchored at the caret's screen coordinates and opens downward, growing with candidate rows and font size. On a small display, large type, or a multi-row list, it easily covers the caret's own line. Composition is exactly when context is needed: the language model uses prior text, and so do people choosing among homophones. Covering that text blinds the human check even if the model still sees the buffer. Inline composition (underlined pinyin in the line) helps some, but the candidate strip may still cover the next line. Unlike a magnifier, which exists to reveal the caret, the candidate window exists to show options; when the two aims conflict, the window usually wins and the source text loses.

Studying it

Record at various font sizes, line heights, and window positions, and mark whether characters covered during composition belong to the current sentence's already-committed part. Dependent measures: homophone mis-picks blamed on unseen context, and how often users drag the window away. Compare floating windows with in-line candidates. Eye tracking shows whether people peek around the window edge at covered glyphs. Empty-document single characters will not measure context occlusion.

Where it stops holding

A huge screen and a tiny candidate window make the covered area negligible. Candidates docked on top of a phone keyboard occlude the keyboard, not the text, and the problem moves to keyboard occupancy. Full-screen game chat with almost no prior text is barely harmed by covering it. Vertical text whose caret anchor is still computed as horizontal will park the window on the wrong paragraph.

Applying it

• Default the window to miss already-committed text on the current line; slightly farther is better than covering the previous word.
• Offer inline composition so pinyin stays at the caret and the candidate strip lives in a fixed band off the line.
• Allow a temporary drag, and remember the offset relative to the caret for the next composition.
• Verify at the target font size, composing the second word of a sentence that already has context, that the first word remains fully visible. Coverage is a failure.

Related

• Same group: C6.27.2 Candidate windows must flip with the caret's distance to the screen edge · C6.27.3 A candidate window that covers controls below the field blocks what comes next · C6.27.4 Dismiss timing must be consistent, or leftover overlays remain
• Adjacent: C6.12 IME candidates · C6.14 Magnifiers and fine caret control
• Search: IME candidate window · occlusion · caret-relative popup