RichText

RichText is the widget for text that cannot stay uniform.

Use it when one block of text needs multiple styles, inline emphasis, mixed semantics, or even inline widgets. If the whole string shares one style, Text is usually the clearer choice.

Example

use fission::prelude::*;
let widget: Widget = RichText::new(vec![
    RichTextRun::new("Build status: "),
    RichTextRun::new("Passed")
        .weight(700)
        .color(view.env.theme.tokens.colors.primary),
])
.max_lines(1)
.into();

This keeps one logical sentence together while still giving the status word special emphasis.

Content table

Field	Type	Meaning	Notes / default behavior
id	Option<WidgetId>	Stable widget identity.	Defaults to None.
runs	Vec<RichTextRun>	The styled runs that make up the text block.	RichText::new(...) fills this for you.
inline_widgets	Vec<InlineWidgetSpan>	Inline widgets embedded in the text flow.	Usually produced through RichText::from_spans(...), not built manually.
annotations	Vec<RichTextAnnotation>	Advanced semantic and interaction annotations over byte ranges.	Usually generated from span builders rather than authored by hand.
semantics	Option<Semantics>	Optional wrapper semantics for the whole block.	Defaults to None.

Layout and typography table

Field	Type	Meaning	Notes / default behavior
width	Option<f32>	Fixed width.	Defaults to None.
height	Option<f32>	Fixed height.	Defaults to None.
min_width	Option<f32>	Minimum width.	Defaults to None.
max_width	Option<f32>	Maximum width.	Defaults to None.
min_height	Option<f32>	Minimum height.	Defaults to None.
max_height	Option<f32>	Maximum height.	Defaults to None.
wrap	bool	Whether lines may wrap.	RichText::new(...) and from_spans(...) set this to true. Raw Default construction does not.
text_align	IrTextAlign	Paragraph alignment.	Defaults to the intermediate representation (IR) default.
text_direction	IrTextDirection	Paragraph direction.	Defaults to the IR default.
text_width_basis	IrTextWidthBasis	Width calculation policy.	Defaults to the IR default.
max_lines	Option<usize>	Maximum number of visible lines.	Defaults to None.
overflow	IrTextOverflow	Overflow behavior for clipped text.	Defaults to visible overflow.
strut_line_height	Option<f32>	Paragraph strut line height.	Defaults to None.
text_height_behavior	IrTextHeightBehavior	Paragraph height trimming behavior.	Defaults to the IR default.
selection_range	Option<(usize, usize)>	Highlighted text selection range.	Defaults to None.
selection_color	Option<IrColor>	Selection highlight color override.	Defaults to None.
selection_text_color	Option<IrColor>	Selected text color override.	Defaults to None.
flex_grow	f32	Extra width or height the text block may absorb in flex layout.	Defaults to 0.0.
flex_shrink	f32	How much the block may shrink in tight layouts.	Defaults to 0.0.

Practical model

There are two common ways to build rich text. For simple styling changes, RichText::new(vec![...runs...]) is enough. For more advanced cases such as inline widgets, hoverable spans, or nested semantics, the span-based constructors are the better fit because they generate the annotations and inline-widget bookkeeping for you.

In both cases, the widget stays declarative. You are still describing the paragraph from state, not mutating a text object in place.

Specific advice

Reach for RichText because the content truly needs mixed styling or inline semantics, not because it feels more powerful. When uniform text is enough, Text is easier to read and maintain.

Production checklist

For RichText, review the fields that change behavior before treating the widget as finished: id, runs, inline_widgets, annotations, semantics. The goal is to make the product rule visible in state and actions, not hidden inside ad-hoc construction code.

•

If this widget appears inside an interactive flow, keep the surrounding action binding in the parent component and test that the flow still has one clear reducer path.

•

Set id only when identity must be stable across filtering, reordering, diagnostics, or tests; otherwise let Fission derive identity from structure.

•

Use semantics when visible content alone is not enough for assistive technology, especially for icon-only controls or custom surfaces.

•

Add at least one component or harness test that confirms the visible text, semantic role, action dispatch, and layout constraint that matter for this widget in context.

If a screen starts repeating the same RichText setup, extract a named component around this widget. That keeps the reference API small while making product code easier to read and safer for generated code to copy.

Text, RichTextRun, TextRunStyle, and TextContent.