docs(design): plan the inline formatting step

[andiwand]

🤖 Generated with Claude Code

The editing plans named inline formatting as the one open step and held one sketch for it, setMark {ids, mark, on}, over four properties. The sketch does not carry colour or size, because they are values and not toggles.

docs/design/document-editing.md gets the section for it:

• the seven properties (bold, italic, underline, strikethrough, highlight, colour, size) and where ODF, docx and pptx keep each one, matching what the three style readers read today;
• the op setTextStyle {id, style}, carrying values rather than toggles, one run per op;
• decisions 8 to 16: off is written and never removed, a run gets a style container of its own (text:span / w:r / a:r), ODF reaches a mark through a fresh automatic style, w:rPr keeps its schema order, highlight is the character background with the docx w:highlight / w:shd split, the editor writes the renderer's css, and the two ways a gesture reaches the editor;
• the adapter surface, four steps of work, and the open questions.

The gate. Formatting sits behind HtmlConfig::editing_scope: under paragraph every formatting gesture refuses with outOfScope, and only document takes it. editing.md states it in the scope table.

Two findings from the code shape the plan: in all three writing engines the addressed run shares its container's style with its siblings, which text_insert relies on; and translate_text_style writes two text-decoration declarations for a run that is both underlined and struck through, so the second wins. No reference page hits that case.

editing.md and the roadmap in docs/design/README.md follow. Docs only, no changelog entry.

The code lands in stacked PRs on top of this one: the renderer fix, the op with the ODF write side, docx and pptx, the browser editor, the bindings.

https://claude.ai/code/session_0137vd79NGaB8nfLsdPoghM4