One geometry for text, selection, and native input

A heading and a paragraph use different type sizes and line spacing. A selection passing through both needs to follow those differences while remaining one continuous text range.

We use CoreText layout as the common foundation for the text we draw, the selection we show, and the geometry we report to native input. In a custom block editor, those three views of an edit have to agree.

A line can contain several fonts, scripts, styled words, and emoji. The visible result depends on shaping and line layout. Counting letters or assigning an average width cannot describe it accurately.

CoreText gives us the typeset lines. We use their layout when drawing the text, locating the caret, and constructing the highlight for a selected range.

The common source matters when the text changes. A line wrap is one consequence; a selection spanning different text styles is another. Updating the paragraph while leaving its selection geometry behind would give the writer two conflicting versions of the same edit.

Phrase supports a continuous text range across blocks. A selection can begin partway through a heading and end partway through another paragraph. The range describes the text being edited; the highlight follows the geometry of each part.

That lets the document keep its structure without making a block boundary an artificial stopping point for revision. We preserve the words outside the selection and leave the caret at the result when the range is replaced.

Whole-block selection serves a different purpose. It gathers complete items for operations such as reordering. The gesture demonstrations show that distinction in the actual editor.

The system can request text geometry while an edit is in progress. On iPhone, we provide it through UITextInput. Our Mac editor uses NSTextInputClient for its platform integration.

Those requests must describe the same layout as the visible caret and selection. An input method choosing a candidate needs the current writing location, including when provisional text changes the shape of the paragraph.

We treat the geometry as part of the edit's result. Text changes, width changes, and scrolling can all affect where the active range appears. The native input response has to follow that settled state.

Long documents add another constraint: much of their content is outside the viewport. We can defer some distant layout work, but a caret request is an immediate request for usable geometry.

Our Mac layout resolves an estimated target before using its position for input. It also makes mounted text exact before presentation. Those rules let the long-document optimization coexist with a precise editing surface.

The block editor architecture article explains how that fits with view reuse, incremental layout, and deferred refinement.

Keeping an active line visible does not mean pulling the page back whenever the writer scrolls away. A person may be checking an earlier passage before continuing the current sentence.

We coordinate cursor visibility with editing and deliberate navigation. The editor needs the right geometry when typing resumes, and it needs to respect the reader's control while they move through the note.

IME composition adds the case where the text itself is still provisional. The same geometry needs to hold through each candidate change.

You can try the cross-block selection in Phrase for iPhone: select part of a heading and part of the paragraph below it, then replace the passage.