Public customization hook for rendering links and inline elements

[advanc3dUA]

Motivation

It would be useful to have a public API for customizing the rendering of specific inline elements, particularly links, beyond the properties currently exposed through InlineStyle.

One concrete use case is link underlining.

SwiftUI's native underline rendering performs ink skipping around glyphs that intersect the underline (for example g, p, y, /, etc.). Text.LineStyle allows configuring the pattern and color, but does not provide control over properties such as the underline offset or ink skipping.

For some designs, we need links to have a continuous underline positioned slightly below the text.

For example:

InlineStyle()
    .link(...)

can currently configure the standard text properties, but there does not appear to be a public way to replace the native underline rendering with a custom one.

Proposed API / extension point

It would be great if Textual exposed enough information about inline elements to allow a custom TextRenderer (or another rendering hook) to identify them.

Links are already represented internally with link-specific attributes, so exposing this information through a public API could enable something conceptually like:

for run in layout {
    if run.isLink {
        context.draw(run)

        // Custom link decoration
        drawUnderline(
            for: run,
            offset: 2
        )
    }
}

The exact API does not necessarily need to be link-specific. A generic way of identifying semantic inline elements from a custom renderer would probably be even more useful.

What this would enable

This would make it possible to implement custom inline decorations without forking or modifying Textual, including:

• custom underline offset;
• continuous underlines without native ink skipping;
• custom underline thickness or geometry;
• dashed/dotted/custom link decorations beyond Text.LineStyle;
• backgrounds or highlights for specific inline elements;
• custom rendering for links while preserving Textual's parsing and interaction handling;
• different rendering for other semantic inline elements in the future.

It would also keep these presentation concerns in application code rather than requiring a Textual fork for relatively small design-system requirements.

Current workaround

As far as I can tell, achieving this currently requires modifying Textual because the information necessary to reliably identify link runs during custom rendering is not exposed through the public API.

Would exposing the relevant inline/link attribute to TextRenderer, or providing a dedicated inline rendering hook, fit the direction of Textual's API?