Portable Text – JSON rich text specification for content editing platforms
Even after arguing in favor of XHTML here in another comment, I&#x27;d like to make a separate &quot;modest proposal&quot;:<p>What if we had a limited kind of markup as <i>part of Unicode</i>, such that <i>all</i> Unicode text could be &quot;marked up&quot;, entirely-portably, such that as long as you aren&#x27;t rewriting the Unicode representation, you&#x27;re preserving the markup?<p>Unicode already handles many kinds of markup. We just don&#x27;t tend to think of these features of Unicode as &quot;markup&quot;—even though many of them have one-to-one equivalents in <i>markup</i> languages!<p>Most obviously, you&#x27;ve got newlines, the plaintext equivalent of the HTML &lt;br&gt; tag. If Unicode was &quot;just&quot; about representing text, newlines (and horizontal&#x2F;vertical tabs, non-breaking spaces, zero-width non-joiners, etc.) wouldn&#x27;t be part of it. These aren&#x27;t text; they&#x27;re <i>instructions</i> to a text <i>layout</i> engine, for where to <i>put</i> the text. They&#x27;re markup, just as much as an HTML &lt;center&gt; tag is!<p>Less obviously—but more flagrantly—Unicode has the BIDI LTR&#x2F;RTL instruction codepoints, and support for storing and representing a <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Ruby_character" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Ruby_character</a> gloss of a given character-sequence embedded alongside said text.<p>And because of this support, Unicode font rendering engines already have everything they need to be able to render a given &quot;meta-instruction&quot; codepoint that makes a given &quot;run&quot; of characters bold, or italic, or small-caps, or strikethrough; or to indicate that a given run of codepoints should be considered a list item, or even a semantic &quot;paragraph&quot; or &quot;heading.&quot;<p>It&#x27;s my understanding that the maintainers of the Unicode standard would balk at standardizing this kind of markup within Unicode. But, if all this is possible at the Unicode-parsing <i>level</i>, then why not just create a separate working group who will maintain such markup codepoints as a Unicode Private-Use Area, and then get font-rendering-engine vendors to support said markup codepoints?<p>---<p>Side-note: the result would be a lot like creating Unicode-codepoint equivalents for ANSI escape sequences, wouldn&#x27;t it? In fact, I would imagine that pretty much every common ANSI &quot;Select Graphic Rendition&quot; escape sequence would make sense as a Unicode markup codepoint, save for maybe being translated to prefix-length or per-grapheme-cluster-paired forms rather than being modal switches.<p>And oddly, I think that such SGR-equivalent codepoints <i>would</i> be within the spirit of Unicode. Unicode wants to allow for the digitization and standards-based preservation of all historical text. Well, how are you supposed to preserve the text-art sent by an 80s BBS, without being able to represent (at least) fg&#x2F;bg color changes? Unicode <i>already</i> decided to standardize the DOS box-drawing characters <i>for exactly this same reason</i>!