The substrate’s transition to editability will need to present a “mostly rendered” view of itself – managed by some form of rich text editor. A huge “grab-bag list” is at JefMari’s curated list of Awesome Wysiwyg Editors which can rapidly be whittled down to a shortlist. CKEditor 5 and TinyMCE are familiar from decades ago. But the gold standard is clearly Marijn’s ProseMirror – basic example here and really nice markdown editing example here.
It feels as if an Infusion component tree could very easily be the backing of one of Marijn’s document models but we’d need to produce a schema. Indeed the whole thing is feeling rather heavyweight and not the kind of thing we could bash into a demo in a couple of weeks. A checkin confirms that a minimal sort of bundle size of ProseMirror is in the region of 200K, Marijn concurs. TinyMCE and CKEditor don’t seem much different.
In the meantime we run into a principled rant from a former mathematician and Medium Engineering lead Nick Santos Why ContentEditable is Terrible. I’ve often reflected that perhaps the only benefit of my mathematical education is equipping me to tell anyone armed with an impressive abstraction to eff off, but the analysis here seems sound and warns of pretty dreadful problems if we start round-tripping stuff in earnest. Along the way we run into Steve Yegge’s salutory 2004 rant on the Nonesuch Beast which warns us that what we are trying to do is likely impossible — “People need to understand when they’re asking for something that’s going to be too complex to learn and use.”
But still — we need to get off the ground more quickly and carry less
weight with us for a while. Let’s put these warnings in our back pocket and look for something a bit more minimal.
This Reddit thread
gives a few pointers but TipTap is itself based on ProseMirror. The AI suggestions for “rich text editor with smallest bundle size”
bring up the hilariously named Trumbowyg which is sadly jQuery-based and then
the peculiarly promising Pell which weighs in at an amazing
145 lines. The live demo seems perfectly reasonable, and when we look at the
implementation, we find that it is, surprise surprise, based wholly around contentEditable!
This really does feel like something we can work with[^1], and morning noodlings suggest that contentEditable might not
have to be such a great unwashed. For a start, if we are tracking provenance of each rendered region to its source,
each one might need to be editable (or read-only) in a different way anyway. We should research what the effects are
of stringing together adjacent sibling nodes with contentEditable versus promoting up to the parent.
In any case we have a workable lift-off vehicle – the entire (tiny) design can be Infusionised and first experiment is to check that it is perfectly workable to embed a self-hosted demo inside Infusion’s README file – it’s puzzling that pell’s own demo takes the form of a little video.
[Edit 2025-03-30:] This experiment failed, as one might have predicted it would. Of course we can’t inject arbitary JavaScript into
GitHub’s rendering of the README markdown in its own interface. It appeared there might be a
loophole involving
the use of SVG files referencing a foreignObject holding arbitrary HTML but it seems that GitHub carefully renders
any images in a sandboxed environment
which are then hosted in a special domain camo.githubusercontent.com. We’ll have to host our experiment in a
standard GitHub page. Looks like there was a live demo on Jared’s personal Netlify website as recently as 2024.
[^1] And to me the “pell” name is a pleasing signpost back to the great Pelle Ehn one of the founding fathers of malleable software thinking.