Generic text spans [foo] with special cases

Iʼm writing an extension that reimagines link syntax as a special case of a generic text span syntax with a pair of square brackets [] where the first of the attributes in the info string, which is everything either inside round parentheses () or after the colon : in a reference definition, is a destination. That means, unless special conditions are met, [foo] converts to <span>foo</span> and [foo](bar) converts to <span bar>foo</span>.

Special Cases

I want to support all commonly used HTML inline (non-form) element types that do not have a better established syntax in core Commonmark or popular extensions. They are currently triggered as follows:

  • [foo](<bar>): <a href="bar">foo</a>
  • ["foo"](<bar>): <q cite="bar">foo</q>
  • [foo]("bar"): <abbr title="bar">foo</abbr>
  • [foo]((bar)): <ruby>foo <rp>(</rp><rt>bar</rt><rp>)</rp></ruby>
  • [foo]([bar]): <time datetime="bar">foo</time>
  • [foo](=bar): <data value="bar">foo</data> (or ! or ??)
  • [foo](:bar): <cite lang="bar">foo</cite>
    [foo](:): <cite>foo</cite>
  • [foo](#bar): <dfn id="bar">foo</dfn>
    [foo](#): <dfn>foo</dfn>

Attributes only

Some (primary) attribute types do not trigger a special element type:

  • [foo](.bar): <span class="bar">foo</span>
  • [foo](@bar): <span data-bar="bar">foo</span>
    [foo](@bar=baz): <span data-bar="baz">foo</span>
    [foo](bar=baz): <span bar="baz">foo</span>
  • [foo]({bar}): <span style="bar">foo</span>
  • [foo](+bar): <span bar="bar">foo</span>
    <span bar="on">foo</span>
    <span bar="true">foo</span>
    <span bar="1">foo</span>
  • [foo](-bar): <span bar="">foo</span>
    <span bar="off">foo</span>
    <span bar="false">foo</span>
    <span bar="0">foo</span>

To do

I have not yet developed indicators for some element types, mostly because they do not have a mandatory or frequent attribute, maybe they would just take a single-char indicator:

  • [foo](^): <kbd>foo</kbd>?
  • [foo]($): <var>foo</var>

Compatibility

I assume the following conventions for other HTML markup, some are commonly implemented that way already, others are systematic innovations:

  • *foo*: <em>foo</em>
  • **foo**: <strong>foo</strong>
  • ****foo****: <mark>foo</mark> (elsewhere ==foo==)
  • _foo_: <i>foo</i>
  • __foo__: <b>foo</b>
  • ____foo____: <u>foo</u>
  • ~foo~: <sub>foo</sub>
  • ~~foo~~: <s>foo</s>
  • ~~~~foo~~~~: <del>foo</del> (elsewhere interchangeable with <s>)
  • ^foo^: <sup>foo</sup>
  • ^^foo^^: <small>foo</small> (unusual, alternatively [foo](_))
  • ^^^^foo^^^^: <ins>foo</ins> (elsewhere ++foo++)
  • `foo`: <code>foo</code>
  • ``foo``: <samp>foo</samp> (or [foo](&)?)
  • ````foo````: <tt>foo</tt>
1 Like

I see what you’re attempting the achieve here: a generic syntax that can be reused for a wide range of elements and attributes. It’s a worthy goal, but it also seems to be moving further away from Markdown’s goal of being “publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.” Would this extension produce a more readable document than just using the named HTML elements and attributes where the meaning is explicitly written in English?

1 Like

I share @chrisalleyʼs concern in general, but I think that with shortcut reference syntax this syntax extension remains quite readable and particularly so for any elements that either require a certain kind of attribute or strongly demand one. The two entries in the To Do section should probably be solved differently.

Where unambiguous, one could furthermore make the round parentheses or square brackets or both optional, e.g. [FOO]("bar") = [FOO]"bar" = FOO("bar") = FOO"bar". Iʼm not fully convinced about that, though. It has worse backwards compatibility.