Inline node support in 2026?

[michael]

For context, I'd very much like to see support for inline nodes (arbitrary content rendered inside a text flow) eventually in Svedit core. That said it's not a high priority for me personally at the moment, at the same time there's Svedit users that would like to see this land rather sooner than later. So there's demand:

See https://x.com/JohannesMutter/status/2034261016368799946 by @johannesmutter and #144 by @mpreziuso .

In terms of how to implement this, there's two directions to explore:

• A) Inline nodes represented as annotations on top of text. Each inline nodes is represented as a single character (e.g. "$") that is rendered with a custom component. See experimental PR [EXPERIMENTAL] Inline nodes #146, but also ProseMirror's dino example
• B) Achieve the result by representing a "rich text" as a horizontally layed out node_array. This would already work in principle, but the primitives (node selection) are not made for partial text selection across multiple nodes etc.

Next steps:

1. Feasibility exploration

• A is considered feasible, and there's a rough prototype ([EXPERIMENTAL] Inline nodes #146)
  • can interactivity inside the inline nodes exist (at your own risk) or will it likely interfere with Svedit's selection mapping?
  • what are the advantages/disadvantages of this model in comparison to B?
    • Pro: A has classic text selection as people are used to from MS/Word etc.
    • Pro: Will only affect isolated parts of Svedit (text selection mapping needs to be improved)
• B is to be explored
  • can you model text with inline nodes using horizontal layout? How about line-breaks?
  • the current API can be used to test if this works in principle, leaving aside clunky usability for editing text
  • what new interactions would it need to make text editing feel natural (special text-ish node cursors), commands to insert non-text things at a certain cursor position (splitting up nodes accordingly)
  • pro/cons of B
    • Pro: might reduce the amounts of concepts (no concept of an annotation anymore, just text properties and nodes that can hold text or more)
    • Con: representing all text with B might be overkill for areas that require just plaintext

2. Decision on a data model (if B route is taken, clarify if a new selection type needs to be introduced - aka multi-nodes-spanning-text-selections)
3. Stable implementation (minimal, no optimizations, no extras, just bringing in the foundational concept in stable way)
4. Final implementation (polished version, e.g. including optimized visuals, refactored code, extensive testing, this feature must not destabilize existing concepts)

My current thoughts (they may change)

• This is a risky endeavor
  • may destabilize current implementation, and introduce edge cases at the intersection of inline nodes and regular text
  • may add complexity to the library, current set of primitives is pretty pure, will it still be?
  • however, if done right, ensuring it's stable, this might be a high-reward feature, as it allow more creative ways to express yourself on a Svedit canvas.
• current feeling is that if A is feasible, it should be preferred as it's a more isolated extensions, whereas B is more or less a rewrite of Svedit, if we want to achieve similar text-editing behavior as inside a current AnnotatedText
• I have limited time resources on this in the coming months as my main priority is pushing editable.website over the finish line

[johannesmutter]

I've been exploring some of the feasibility questions you raised for Route B. Not conclusive yet, but promising enough to share.

Can you model text with inline nodes using horizontal layout?

Yes, and there are more CSS tools available than I expected:

display: ruby (W3C spec) lets block-ish elements participate in inline text flow, including wrapping. Some older CSSWG discussion: 1, 2. Anchor-positioned gaps also work here, though with some misplacement depending on padding/margin.

CSS grid lanes are another candidate worth prototyping with.

A more radical option: treat every whitespace as a node boundary (one word = one node). This sidesteps the wrapping problem entirely.

How about line breaks?

Probably easy to fix as discussed yesterday with preprended <br> or margin-inline-start.

Selection across node boundaries

The foundation for cross-node selection is already there. There are details to work through in the selection mechanism, but I think the goal shouldn't be replicating classic text selection. There's room for something that actually works better for this model. A model that no longer bothers the user with individual characters, but introduces new gestures for editing content, not strings of characters.

What B would actually unlock

The thing that excites me about B isn't just reducing concepts (though that matters: no annotation layer, just nodes and node arrays, a cleaner mental model for developers — and users, as what developers do smells through in the final UI).

It's what becomes possible when rich text is just a node array: the same data can render as flowing prose or as a spatial layout like a mindmap, depending on the view. Collapsing & expanding content inline, etc. Interactive objects live inside text as first-class nodes, not as special cases patched onto an annotation system. That's a fundamentally different foundation, one that aligns with where interface design is heading, with natural language (chat, etc) becoming primary modes of interaction.

I realize this is harder to evaluate upfront than A. The value of B becomes concrete through prototyping, not through comparison tables: which is part of why I'd rather turn the open questions into a challenge list we work through than try to weigh pros and cons in the abstract. A is knowable now; B needs exploration to reveal what it actually is.