react-x11 2.52.0 → 2.53.0

package/docs/ecosystem/forms.md

@@ -1,14 +1,14 @@
 # Forms and validation
 
-There is no `<form>` element here, so nothing submits itself — wire
+There is no `<form>` element, so nothing submits itself — wire
 `handleSubmit` to a `Button`'s `onPress` or to `<textinput onSubmit>`.
 
-Everything else follows from **one signature**. Every value control in the
-library — the host elements `<textinput>` and `<textarea>`, and the widgets
-`Checkbox`, `Switch`, `RadioGroup`, `Select` and `Slider` — calls
-`onChange(ev)` with a change event carrying `ev.value`, `ev.target.value`,
-`ev.target.name` and, for a checkbox, `ev.target.checked`. That is the shape
-every DOM form library reads, so a library's handler goes straight in:
+Everything else follows from **one signature**. Every value control — the
+host elements `<textinput>` and `<textarea>`, and the widgets `Checkbox`,
+`Switch`, `RadioGroup`, `Select` and `Slider` — calls `onChange(ev)` with a
+change event carrying `ev.value`, `ev.target.value`, `ev.target.name` and,
+for a checkbox, `ev.target.checked`. That is the shape DOM form libraries
+read, so a library's handler goes straight in, with no per-widget bridge:
 
 ```jsx
 <textinput name="host"  value={f.values.host}   onChange={f.handleChange} />
@@ -16,9 +16,6 @@ every DOM form library reads, so a library's handler goes straight in:
 <Select    name="size"  value={f.values.size} options={sizes} onChange={f.handleChange} />
 ```
 
-No adapter, no per-widget bridge, nothing to remember about which control
-you are wiring.
-
 | library                | how it goes in                                            |
 | ---------------------- | --------------------------------------------------------- |
 | `react-hook-form`      | `{...register('host')}`, or `<Controller>` for a widget   |
@@ -26,43 +23,36 @@ you are wiring.
 | `downshift`            | `getInputProps()` spread onto a `<textinput>`             |
 | `@tanstack/react-form` | `onChange={(ev) => field.handleChange(ev.value)}` — below |
 
-Every row was established by running the library headless against this
-renderer rather than by reading its documentation: react-hook-form@7.84.0,
+Each row was run headless against the renderer: react-hook-form@7.84.0,
 formik@2.4.9, downshift@9.4.0, @tanstack/react-form@1.33.2.
 
 **The one thing to know**: a library whose field contract is
-value-in/value-out — TanStack Form is the one here — needs the value taken
-off the event, and a bare `onChange={field.handleChange}` stores the _event
-object_ as the field value with no error. See below.
+value-in/value-out — TanStack Form here — needs the value taken off the
+event; a bare `onChange={field.handleChange}` stores the _event object_ as
+the field value with no error.
 
-**Where the line falls.** A control that takes a `name` is a form field and
-reports an event. `Tabs`, `Table` and the menus are not form fields
-and keep their plain callbacks
+A control that takes a `name` is a form field and reports an event. `Tabs`,
+`Table` and the menus are not, and keep their plain callbacks
 ([components](../components.md#the-change-event-and-name)).
 
 ## TanStack Form {#tanstack-form}
 
 **Out of the box.** @tanstack/react-form@1.33.2 (form-core 1.33.2).
 
-A headless, framework-agnostic form state manager: field values, dirty and
-touched tracking, sync and async validation (including Standard Schema, so
-zod/valibot/arktype plug in directly), and submission handling. Fields are
-value-in/value-out — no DOM events, no refs.
-
-The field contract is `field.state.value` + `field.handleChange(value)` —
-a **value, not an event**. react-x11's controls fire an event, so each field
-takes the value off it:
+A headless form state manager: field values, dirty and touched tracking,
+sync and async validation (Standard Schema, so zod/valibot/arktype plug in
+directly), and submission. The field contract is `field.state.value` +
+`field.handleChange(value)` — a **value, not an event** — so each field
+takes the value off the control's event, the same expression a DOM app
+writes, for a `<textinput>` and a `Checkbox` alike:
 
 ```jsx
 onChange={(ev) => field.handleChange(ev.value)}
 ```
 
-One expression, the same one a DOM app writes, and it is identical for a
-`<textinput>` and for a `Checkbox`.
-
-Watch for the bare form: `onChange={field.handleChange}` stores the event
-object as the field's value — no error, no warning, and validation sees an
-object where it expected a string.
+The bare `onChange={field.handleChange}` stores the event object as the
+field's value — no error, no warning, and validation sees an object where it
+expected a string.
 
 ```jsx
 import React from 'react';
@@ -101,25 +91,19 @@ function ConnectForm({ connect }) {
 }
 ```
 
-- No `<form>` element exists, so there is no submit-on-Enter for free. Wire
-  `form.handleSubmit()` to a button's `onPress` and/or a window-level Enter
-  key handler.
-- The **widgets** are the exception: `Checkbox`, `Switch`, `RadioGroup`,
-  `Select` and `Slider` still pass the next value first, so
-  `onChange={field.handleChange}` is right there and needs no unwrap. Only
-  the host elements `<textinput>`/`<textarea>` changed.
+- There is no submit-on-Enter for free. Wire `form.handleSubmit()` to a
+  button's `onPress` and/or a window-level Enter key handler.
 - Validation errors from a zod schema are error _objects_
-  (`errors[0].message`), not strings; a plain string validator returns
-  strings. A `<text>` child must be a string, so render `.message`.
-- The package also ships SSR and Next helpers under subpaths; the root
-  import used here pulls in no react-dom.
+  (`errors[0].message`); a plain string validator returns strings. A
+  `<text>` child must be a string, so render `.message`.
+- The SSR and Next helpers live under subpaths; the root import pulls in no
+  react-dom.
 
 ## zod {#zod}
 
 **Out of the box.** zod@4.4.3.
 
-TypeScript-first schema validation. Pure computation, no DOM, nothing
-renderer-specific — the interesting part is only where it plugs in:
+Schema validation, pure computation. Where it plugs in:
 
 - **TanStack Form** — pass a schema straight into a field's
   `validators: { onChange: z.string().min(3, 'too short') }`. Zod 4
@@ -157,49 +141,39 @@ function Settings({ raw }) {
 
 - Zod 4 field errors surface as issue objects; render `issue.message`, not
   the issue itself.
-- `valibot` and `arktype` are equally viable (also Standard Schema). zod is
-  documented here because both verified form integrations used it.
-- Bundle-size arguments from the web world do not apply — an X11 app ships
-  no bundle.
+- `valibot` and `arktype` are equally viable (also Standard Schema).
+- Bundle-size arguments from the web do not apply — an X11 app ships no
+  bundle.
 
 ## React Hook Form {#react-hook-form}
 
 **Out of the box, both APIs.** react-hook-form@7.84.0 with
 @hookform/resolvers@5.5.7.
 
-RHF's headline API is uncontrolled-first: `register()` returns DOM-shaped
-props (`{name, ref, onChange(e), onBlur(e)}`) and reads `e.target.value` off
-the event. That is exactly what `<textinput>` provides, so the terse spread
-works:
+`register()` returns DOM-shaped props (`{name, ref, onChange(e),
+onBlur(e)}`) and reads `e.target.value` off the event, which is what
+`<textinput>` provides, so the spread works:
 
 ```jsx
 const { register, handleSubmit } = useForm({ defaultValues: { host: '' } });
 <textinput {...register('host')} />;
 ```
 
-Three things had to line up, and all three now do: `name` exists as a prop,
-`onChange` receives an event whose `target.value` is the new text, and the
-`ref` RHF attaches lands on a node whose `value` is **writable** — RHF
-assigns `ref.value = ''` while registering the field, which used to throw
-`TypeError: Cannot set property value of #<TextInputNode> which has only a
-getter` from inside the commit phase and take the render down with it.
-
-Verified working through `register()`: typing updates `getValues()`,
-`handleSubmit` receives them, `setValue(name, v)` writes through the ref so
-the field redraws, and `setFocus(name)` focuses the node.
-
-One asymmetry to know about: **`reset()` updates form state but does not
-clear an uncontrolled field's text.** RHF only writes values back through
-refs on the reset path when its `isWeb` probe
-(`typeof window !== 'undefined' && window.HTMLElement && document`) passes,
-which it never does here. `setValue()` is not gated that way and does write
-through. If you need `reset()` to clear the display, make the field
-controlled — `<Controller>`, below — or assign `ref.current.value = ''`
-yourself.
-
-`<Controller>` / `useController` still works, unchanged, and is the better
-choice when you want the field controlled. `field.onChange` accepts either a
-plain value or an event, so both of these are fine:
+The `ref` RHF attaches lands on a node whose `value` is writable (RHF
+assigns `ref.value = ''` while registering). Through `register()`, typing
+updates `getValues()`, `handleSubmit` receives the values,
+`setValue(name, v)` writes through the ref so the field redraws, and
+`setFocus(name)` calls the node's `.focus()`.
+
+**`reset()` updates form state but does not clear an uncontrolled field's
+text.** RHF writes values back through refs on reset only when its `isWeb`
+probe (`typeof window !== 'undefined' && window.HTMLElement && document`)
+passes, which it never does here; `setValue()` is not gated. To have
+`reset()` clear the display, make the field controlled with `<Controller>`,
+or assign `ref.current.value = ''` yourself.
+
+`<Controller>` / `useController` is the choice for a controlled field.
+`field.onChange` accepts a plain value or an event, so both are fine:
 
 ```jsx
 onChange={(ev) => field.onChange(ev.target.value)}   // explicit
@@ -246,11 +220,9 @@ function ConnectForm({ connect }) {
 }
 ```
 
-- A `Controller` field is controlled, so its subtree re-renders on every
-  keystroke. `register()` does not, which is the same performance argument
-  RHF makes on the web — and it now applies here too.
-- `setFocus(name)` works: it calls `.focus()` on whatever the ref holds, and
-  a `<textinput>` node has one.
+- A `Controller` field re-renders its subtree on every keystroke;
+  `register()` does not — the same performance argument RHF makes on the
+  web.
 - `handleSubmit` returns a function. Call it: `handleSubmit(fn)` in an
   `onPress` is the curried form, and there is no submit event to pass.
 
@@ -258,12 +230,7 @@ function ConnectForm({ connect }) {
 
 **Out of the box.** formik@2.4.9.
 
-Formik was the clearest casualty of the old `onChange(string)` contract, and
-it failed _silently_: `handleChange` treats a string argument as its curried
-field-name form, returns a handler, and never touches state — so spreading
-`getFieldProps` onto a `<textinput>` left `values` at its initial object and
-`touched` empty, with nothing logged. That is fixed by the event, not by an
-adapter. All three of Formik's field styles now work:
+All three of Formik's field styles work:
 
 ```jsx
 import { Formik, Field, useFormik } from 'formik';
@@ -286,10 +253,7 @@ import { Formik, Field, useFormik } from 'formik';
 ```
 
 `handleChange` reads `target.name` to decide which field to write, so the
-`name` prop is not optional in any of these — that is what the synthetic
-event carries it for.
-
-The widgets need no bridge — same handler, same signature:
+`name` prop is required in all of these. The widgets take the same handler:
 
 ```jsx
 <Checkbox
@@ -301,13 +265,13 @@ The widgets need no bridge — same handler, same signature:
 </Checkbox>
 ```
 
-`ev.target` is `{ type: 'checkbox', name, value, checked }`, which is exactly
-what `handleChange` destructures — including `type`, which is how it knows to
-take `checked` rather than `value`.
+`ev.target` is `{ type: 'checkbox', name, value, checked }`, which is what
+`handleChange` destructures — `type` is how it knows to take `checked`.
 
 - `<Formik>`'s render-prop form and `useFormik` both work; there is no
   `<form>` element, so call `submitForm()` (or `handleSubmit()`) yourself
   from a `Button` or from `<textinput onSubmit>`.
-- Passing a non-event object to `handleChange` — a hand-rolled fake event
-  with no `target` — still throws `TypeError: Cannot read properties of
-undefined (reading 'type')` rather than no-opping. Pass the real event.
+- Passing `handleChange` a non-event object — a hand-rolled fake event with
+  no `target` — throws
+  `TypeError: Cannot read properties of undefined (reading 'type')` rather
+  than no-opping. Pass the real event.

package/docs/ecosystem/headless.md

@@ -1,19 +1,15 @@
 # Headless components
 
-"Headless" is a promise that gets broken a lot. A library that returns DOM
-prop bags — `getInputProps()`, `useButton()` — is not headless in any sense
-that helps here; it is DOM-coupled with the rendering deferred. The two
-packages below are the real thing: they own state and collections, return
-plain values, and never touch a ref.
-
-Everything else that markets itself as headless is in the
-[negative-results register](../ecosystem.md#what-does-not-work) — Headless
-UI, the Radix primitives and downshift all fail, the last one silently until
-the first keystroke.
-
-For finished widgets, react-x11 ships its own: `Button`, `Checkbox`,
+A library that returns DOM prop bags — `useButton()` and the like — is
+DOM-coupled with the rendering deferred, not headless in a sense that helps
+here. The two packages below own state and collections, return plain values,
+and never touch a ref. Headless UI and the Radix primitives render DOM hosts
+and fail ([register](../ecosystem.md#what-does-not-work)); downshift's
+`getInputProps()` works on a `<textinput>` ([forms](forms.md)).
+
+For finished widgets react-x11 ships its own: `Button`, `Checkbox`,
 `Radio`/`RadioGroup`, `Switch`, `ProgressBar`, `Select`, `Slider`, `Tooltip`,
-`Dialog`, `MenuBar`/`ContextMenu`, `Tabs`, `Table`, `SplitPane`. See
+`Dialog`, `MenuBar`/`ContextMenu`, `Tabs`, `Table`, `SplitPane` — see
 [components](../components.md).
 
 ## react-stately {#react-stately}
@@ -25,13 +21,9 @@ The state-machine half of React Aria: `useListState`, `useTreeState`,
 `useComboBoxState`, `useMenuTriggerState`, `useNumberFieldState` and about
 thirty-five more, plus the `Item`/`Section` collection API. Each hook owns
 selection, disabled-key traversal, expansion and typeahead-ready collections
-— everything a widget needs _except_ rendering and event binding, which is
-exactly the part react-x11 supplies.
-
-There is no seam to bridge: the hooks take props, return state, and never
-touch a ref. A scan of the shipped `dist/` finds no runtime reference to
-`document`, `window` or `getBoundingClientRect` in any hook, and its
-dependencies (`@internationalized/*`, `@react-types/shared`,
+— everything but rendering and event binding, which react-x11 supplies. No
+hook references `document`, `window` or `getBoundingClientRect` at runtime,
+and the dependencies (`@internationalized/*`, `@react-types/shared`,
 `use-sync-external-store`) are DOM-free.
 
 ```jsx
@@ -76,21 +68,18 @@ function Picker() {
 }
 ```
 
-- **Only `react-stately` is portable.** `react-aria` (the hooks that produce
-  DOM props and bind DOM events) and `react-aria-components` are not — do not
-  follow Adobe's docs into `useListBox` or `useButton`, which return DOM prop
-  bags.
-- As of 3.48 the package is consolidated: the old `@react-stately/*` packages
-  are bundled in, with per-hook subpath exports
-  (`react-stately/useListState`) for lean imports.
-- The collection API wants `<Item>`/`<Section>` elements, or an `items` plus
-  render-function pair. It is a compile target of its own, slightly
-  ceremonious for a three-entry menu.
-- `useAsyncList` pulls in fetch-based loading state — fine under Node, but it
-  is the one hook with I/O opinions.
-- Drag-and-drop hooks (`useDraggableCollectionState`) hold state fine, but
-  everything that would _feed_ them events is DOM-side. Expect to write the
-  event plumbing.
+- **Only `react-stately` is portable.** `react-aria` (hooks that produce DOM
+  props and bind DOM events) and `react-aria-components` are not — do not
+  follow Adobe's docs into `useListBox` or `useButton`.
+- Since 3.48 the old `@react-stately/*` packages are bundled in, with
+  per-hook subpath exports (`react-stately/useListState`) for lean imports.
+- The collection API wants `<Item>`/`<Section>` elements, or `items` plus a
+  render function — ceremonious for a three-entry menu.
+- `useAsyncList` carries fetch-based loading state — fine under Node, the
+  one hook with I/O opinions.
+- Drag-and-drop hooks (`useDraggableCollectionState`) hold state, but
+  everything that would _feed_ them events is DOM-side; write the event
+  plumbing yourself.
 
 ## `@tanstack/react-table` {#tanstack-table}
 
@@ -98,21 +87,16 @@ function Picker() {
 react-store 0.11.1).
 
 A headless table engine: column defs, row models, sorting, filtering,
-grouping, pagination, column sizing, visibility and pinning — as pure state
-plus derived row models. It renders nothing; you map `getHeaderGroups()` and
-`getRowModel().rows` to whatever the host renderer draws.
-
-v9 talks about "adapters", and the word means the framework, not the
-renderer: `@tanstack/react-table` _is_ the React adapter, wiring the
-framework-agnostic core's store to React's subscription model. react-x11 is
-React, so that adapter is already ours and there is nothing renderer-shaped
-to write. It still never touches `react-dom` or `document` at runtime —
-though v9 moves two of this page's checks, see the react-dom and `flexRender`
-bullets below. `column.getToggleSortingHandler()` still goes straight onto a
-header `onClick`.
-
-v9's API is modular where v8's was monolithic: features and row models are
-registered up front through `tableFeatures`, and the hook is `useTable`.
+grouping, pagination, column sizing, visibility and pinning, as pure state
+plus derived row models. You map `getHeaderGroups()` and
+`getRowModel().rows` to react-x11 elements.
+
+v9's "adapters" are per framework, not per renderer: `@tanstack/react-table`
+_is_ the React adapter, so there is nothing to write, and it never touches
+`react-dom` or `document` at runtime (but see the react-dom and `flexRender`
+bullets). `column.getToggleSortingHandler()` goes straight onto a header
+`onClick`. Features and row models are registered up front through
+`tableFeatures`, and the hook is `useTable`.
 
 ```jsx
 import React from 'react';
@@ -173,47 +157,38 @@ function Servers({ data }) {
 }
 ```
 
-Sorting is uncontrolled here — the table's own store holds it, and the
-header click re-renders through the adapter's subscription. Pass
-`state`/`onSortingChange` as before to control it, or a selector as
-`useTable`'s second argument to subscribe a component to only some slices.
-
-The natural pairing is inside the existing `Table` component, or raw
-`<box style={{ flexDirection: 'row' }}>` rows: TanStack owns the data logic,
-react-x11 owns painting.
+Sorting is uncontrolled here — the table's store holds it, and the header
+click re-renders through the adapter's subscription. Pass
+`state`/`onSortingChange` to control it, or a selector as `useTable`'s
+second argument to subscribe a component to only some slices. Render into
+the built-in `Table` component or raw `<box style={{ flexDirection: 'row' }}>`
+rows.
 
 - **`coreRowModel` is opt-in, and forgetting it fails silently.** Without
-  `coreRowModel: createCoreRowModel()` in `tableFeatures`, the table
-  constructs, headers render, and `getRowModel().rows` is `[]` — no error.
-  The official examples lean on framework presets that include it; register
-  it yourself.
+  `coreRowModel: createCoreRowModel()` in `tableFeatures`, headers render
+  and `getRowModel().rows` is `[]`, with no error. The official examples get
+  it from framework presets; register it yourself.
 - **npm installs a `react-dom` you must not keep.** `@tanstack/react-store`
-  declares a `react-dom` _peer_ dependency, which npm 7+ auto-installs. The
-  shipped code never imports it — grep test 2 on all four `@tanstack`
-  packages finds one `"button"` in a doc comment, and this section was
-  verified with `node_modules/react-dom` deleted — but a resident react-dom
-  is exactly the [silent-failures](../ecosystem.md#silent-failures) hazard.
-  Install with `--legacy-peer-deps`, or delete it and let `npm ls react-dom`
-  stay empty.
-- **`flexRender` now returns a React element even for a plain string cell**
-  (v8 returned the string itself). Inside `<text>` that is fine — the string
-  arrives as a text chunk and paints identically — but a test or a11y walk
-  that reads a `<text>` node's `children` prop now sees an element object.
-  Read the rendered chunks, not the prop. A column def whose `cell` returns
-  DOM elements still throws the renderer's unknown-element error; return
-  strings or react-x11 elements.
-- Column _resizing_ helpers (`header.getResizeHandler`) still expect DOM
-  mouse or touch events with `clientX`, and now fall back to a
-  `document`-listener drag loop (injectable as `_contextDocument`). Simpler
-  to ignore the helper: write your own drag handling off
-  `onMouseDown`/`onMouseMove` — react-x11 events carry `x`/`y` — and call
+  declares a `react-dom` _peer_, which npm 7+ auto-installs. The shipped
+  code never imports it (test 2 finds one `"button"`, in a doc comment, and
+  the table works with `node_modules/react-dom` deleted), but a resident
+  react-dom is the [silent-failures](../ecosystem.md#silent-failures)
+  hazard. Install with `--legacy-peer-deps`, or delete it so
+  `npm ls react-dom` stays empty.
+- **`flexRender` returns a React element even for a plain string cell** (v8
+  returned the string). Inside `<text>` it paints identically, but a test or
+  a11y walk reading a `<text>` node's `children` prop sees an element
+  object; read the rendered chunks. A `cell` that returns DOM elements
+  throws the unknown-element error; return strings or react-x11 elements.
+- Column _resizing_ helpers (`header.getResizeHandler`) expect DOM mouse or
+  touch events with `clientX` and fall back to a `document`-listener drag
+  loop (injectable as `_contextDocument`). Simpler: handle the drag off
+  `onMouseDown`/`onMouseMove` (react-x11 events carry `x`/`y`) and call
   `table.setColumnSizing` (needs `columnSizingFeature` registered).
-- `useTable` probes `typeof window` to pick `useLayoutEffect`; under Node it
-  gets the `useEffect` branch. That is a grep-test-3 hit of the harmless
-  kind — timing, not a feature gate — and the sorted re-render above runs
-  through it.
-- For thousands of rows, pair it with a virtualizer — see
-  [layout](layout.md#tanstack-virtual). TanStack Table will happily hand you
-  10,000 row objects and let the renderer drown.
+- `useTable` probes `typeof window` to pick `useLayoutEffect` and gets
+  `useEffect` under Node — a harmless test-3 hit (timing, not a feature
+  gate).
+- For thousands of rows, pair it with a
+  [virtualizer](layout.md#tanstack-virtual).
 - State updates driven from outside a React event land one frame later than
-  the call, the same as any react-x11 update.
+  the call, as with any react-x11 update.

package/docs/ecosystem/i18n.md

@@ -4,16 +4,11 @@
 
 **Out of the box.** i18next@26.3.6, react-i18next@17.0.11.
 
-i18next is the de-facto JS i18n core — resources, interpolation, plurals,
-namespaces, backends — and react-i18next binds it to React with
-`useTranslation`, `<Trans>` for translations containing markup, and
-provider-driven re-render on language change.
-
-The core has no DOM in it and react-i18next renders whatever elements you
-hand it, so the whole stack runs unmodified: interpolation, count-based
-plurals, `<Trans>`, and `i18n.changeLanguage('de')` re-rendering the mounted
-tree in place. Node ships full ICU, so `Intl.NumberFormat` and
-`Intl.DateTimeFormat` formatting work too.
+i18next (resources, interpolation, plurals, namespaces, backends) with
+react-i18next's `useTranslation`, `<Trans>` and provider-driven re-render
+runs unmodified: interpolation, count-based plurals, `<Trans>`, and
+`i18n.changeLanguage('de')` re-rendering the mounted tree in place. Node
+ships full ICU, so `Intl.NumberFormat` and `Intl.DateTimeFormat` work too.
 
 Two react-x11-specific rules:
 
@@ -72,18 +67,20 @@ function Status() {
 // i18n.changeLanguage('de') re-renders live
 ```
 
-For loading translations from disk, `i18next-fs-backend` is the natural
-desktop choice; `i18next-http-backend` also works, since Node has `fetch`.
+To load translations from disk use `i18next-fs-backend`;
+`i18next-http-backend` also works, since Node has `fetch`.
 
 ## What is missing below the string
 
-These are react-x11 gaps rather than i18next ones, and they matter more than
-the library choice:
+React-x11 gaps rather than i18next ones, and they matter more than the
+library choice:
 
-- **There is no X input method.** Dead keys and the Compose key are handled
-  in the renderer ([events.md](../events.md#composition)), but there is no
-  XIM/IBus integration, so a language that needs a real input method — CJK —
-  can be _displayed_ but not typed.
-- `<Trans>` with the default `<strong>`- and `<em>`-style numbered tags in
-  translations is fine as long as every referenced component is a `<text>`
-  span. An accidental DOM tag fails loudly at render, which is the good case.
+- **No input method on X11 or Cocoa.** Dead keys and the Compose key are
+  handled in the renderer ([events.md](../events.md#composition)), but
+  there is no XIM/IBus/Fcitx client on X11 and no `NSTextInputClient` on
+  Cocoa, so a language that needs one — CJK — can be _displayed_ but not
+  typed there. The Wayland and Windows backends drive the system input
+  method.
+- `<Trans>` with `<strong>`/`<em>`-style numbered tags is fine as long as
+  every referenced component is a `<text>` span. An accidental DOM tag fails
+  loudly at render.