If I had to type-write an “inline list” properly (in plain text, maybe to be processed as Markdown, or just to be line-wrapped by fmt), I would (have to) use NBSP at certain places, in order to prevent inconvenient or misleading line breaks. In particular, a line break right before the list item markers should be avoided, for otherwise this would not look “inline” any more.
Here’s an example (using ~ as a “visible NBSP”):
This one
Coco's favorites: a) bananas, b) apples, and c) oranges.
could wrap unfortunately into, say
Coco's favorites: a) bananas,
b) apples, and c) oranges
In order to avoid such cases, one could use NBSP (~) like this:
Coco's favorites:~a) bananas,~b) apples, and~c) oranges.
So in principle a tool could figure out, from the hints that the (invisible) NBSPs provide, what is going on here. Though it would not map easily into a document type like HTML without “inline lists”, of course.
In fact, such “inline” lists are so rare (to be seen, or to be represented in a document type) in my view, that it’s probably not worth the effort.
On the other hand, standard document types like DocBook, NISO JATS, ISO 12083:1994 all have paragraph elements whose (mixed) content model includes “ordinary” lists, but there’s no rendering expectation that the list is shown “inline”. There is no specific “inline list”, as this seems more a style and rendering issue, not a question of element structure. (HTML of course has lists only outside the <P> element.)
So an “inline” (or rather “inside-paragraph”) list would have the rather natural (and already existing!) CommonMark syntax:
Coco's favorites:
a) bananas,
b) apples, and
c) oranges,
and I like those too.
which could be mapped to a single DocBook paragraph as
<para>Coco's favorites: <orderedlist><listitem>bananas, </listitem>...</orderedlist> and I like those too.</para>
whereas—for DocBook etc—the following means something rather different:
Coco's favorites:
a) bananas,
b) apples, and
c) oranges,
and I like those too.
Namely one paragraph, a list, and then another paragraph.
Similarly, (to the NBSP remark above) if I would format a “definition list” in a typescript (ie, a plain text file, with no knowledge of Markdown), it would look maybe something like this:
bit:
Binary digit; that is, either zero or one.
DTD:
Document type definition:
Rules, determined by an application, that [...]
In Markdown (without genuine “definition lists”), there would be (have to be!) two SPACEs following the COLONs after the terms. (And a “\” preceding the “[” …
)
From the parsing result from cmark
<p>bit:<br />
Binary digit; that is, either zero or one.</p>
<p>DTD:<br />
Document type definition:<br />
Rules, determined by an application, that [...]</p>
a tool could again figure out what is meant here (“a paragraph starting with a single line ending in a COLON and then <br>? – looks like a <DT> to me!”) And of course cmark could figure that out all alone.
I think what I want to say here is that before sprinkling “special characters” all over the text maybe a better start is a “conventional plain text formatting rule” one could and would apply using a good-old typewriter, and try to recognize this in the parser. At least this seems more aligned with Gruber’s “philosophical” principle
Readability, however, is emphasized above all else. A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. — Gruber: Markdown Syntax