<ins> native syntax as semantic counterpart to ~~ (<del>)

[Rangdy-Kor]

Summary

GFM introduced ~~text~~ as native syntax for <del> to express deletion in a diff context. However, its HTML5 semantic counterpart <ins> — which represents insertion — has no equivalent native syntax. This creates an asymmetry that leaves diff markup only half-supported at the syntax level.

This proposal also suggests a concrete syntax: ~text~ for <ins>.

Problem

<del> and <ins> are defined as a pair in the HTML Living Standard, both intended to mark up changes to a document:

• <del> → content that has been removed
• <ins> → content that has been added

GFM natively supports one but not the other. Users who want to express insertion semantics must fall back to raw HTML (<ins>text</ins>), while deletion has a clean, first-class syntax.

This is not a request for a visual underline. The distinction matters: this is about semantic markup for document diffs, which is precisely the use case GFM's <del> extension was designed for.

Real-world contexts where <ins> semantics are needed include PR reviews, document revision histories, and legislative amendment markup — all cases where <del> alone is insufficient.

Proposed Syntax

This proposal suggests ~text~ (single tilde on each side) as the native syntax for <ins>.

This syntax has several properties worth noting:

• It does not conflict with the existing ~~text~~ strikethrough syntax.
• It follows the same principle as bold and italic — repeating the same token, with the number of repetitions determining the effect (~ for insertion, ~~ for deletion).
• It mirrors the relationship between * (italic) and ** (bold), making the system consistent and learnable.
• Within the current GFM spec, a single ~ is an unassigned token — it carries no syntax meaning and renders as a literal character. This proposal fills that gap rather than repurposing or overloading an existing construct.

One corollary worth addressing: ~~~text~~~ (triple tilde) might naively seem like a candidate for applying both <ins> and <del> simultaneously. However, since ~~~ is already used as a code fence delimiter, this combination should be excluded from the spec to avoid ambiguity.

It is also worth noting that some existing Markdown parsers (e.g. Pandoc) already use ++text++ for <ins>. While ~text~ is proposed here as the more aesthetically consistent choice given GFM's existing ~~ convention, the prior art around ++ may be relevant to the discussion.

Why This Is Different from Previous Underline Requests

Past proposals for underline syntax (e.g. talk.commonmark.org) were rejected on the grounds that Markdown should not be a tool for visual styling. That reasoning does not apply here.

<ins> carries document-level semantics, not presentational intent — the same argument that justified adding <del> support in the first place. Applying that reasoning here, while ~~ for <del> remains in the spec, would leave the two semantically paired elements treated inconsistently at the syntax level.

References

• HTML Living Standard — <ins> and <del>
• GFM Spec §6.5 — Strikethrough

[waldyrious]

I won't spend much time responding to a text that's been obviously AI-generated (or at least strongly AI edited), but just a couple of points:

• markdown already has plenty of issues with ambiguous syntax like * standing for both italics, bold and unordered list items, _ being used for italics by some renderers regardless of amount, and as bold when doubled in some other renderers, etc. We shouldn't compound these issues further by making ~ (already an extension and thus not universally supported) behave differently depending on the number of tildes (not to mention the overlap with code block notation already acknowledged in the text above)
• it's quite puzzling how this proposal acknowledges precedent for using ++ as an <ins> marker, and still decides to go with a more ambiguous single ~, with zero prior usage (AFAIK), as the primary suggestion. I mean, the solution is right there already!

In any case, as far as I can tell this project is abandoned so there isn't much point in discussing hypothetical adjustments to it as they're most likely not going to be applied regardless of their merit.

[UziTech]

Within the current GFM spec, a single ~ is an unassigned token

Not true according to the GFM spec:

Strikethrough text is any text wrapped in a matching pair of ONE or two tildes (~).