Strikeout threw out? Strikethrough strikes out, throughout?

+++ Vitaly Puzrin [Oct 27 14 05:55 ]:

What do you think about Critic Markup feature of marking cross-paragraphs ranges? Looks like very big collision with 2-level concept of markdown (blocks + inlines). Will it be valuable enougth, if limited by inlines only?

That was one of my worries about it. Another is that, in editing, you might e.g. want to strikeout part of a code block—but of course we wouldn’t support markup in a code block in any case. But a form of it that is limited to inlines might still be useful.

1 Like

I backed out of this conversation for a bit, because I’m not really an expert in all this, but I just wanted to post this babelmark result, to try and underline the one point that I came here to make,

which is that there is already a consensus. Obviously (this is markdown after all) it’s a split consensus, but frankly I only see two options here: follow John Gruber, or everyone else.

1 Like

that combined with 45 -- 47 is still very much different compared to the other form of
--strikethrough this sentence--. So having a <s> version that won’t conflict with em-dashes should be possible.

Agreed with @Buddy statement that ~~strikeout-- (for <del>) has a presence, especially in pandoc, as a critic’s markup. Still think it is safer with critic’s markup {~~ ~~} form, in terms of finer control over removing spaces. (could perhaps be optional 2nd form to ~~strikeout--, and have both forms. )

Thanks for the mailing list link. There has been some discussion about using Critic Markup over in the Reviewing Markups topic on this forum. Using the Critic Markup syntax {-- for deletion seems sensible. Perhaps ~~ could still be used in non-review contexts. For example, text that is no longer accurate or relevant, but is not intended to be deleted from the document. This is what the <s> element is used for in HTML5, distinct from <del>.

1 Like

I often need markdown, usually in GitHub issues when I am corrected in lower comment or somewhere, I strikethrough the wrong content and then write the correct one.

It’s also useful when situations change like today at one Discourse I first talked about ~Manjaro~~ and then moved to talking about Antergos and strikethrough would have been helpful.

Googling I learned that <s> and <del> exist, but I am already used to GitHub flavoured markdown and probably many other people too.


Probably not a pattern that survives outside of hard core programming communities like GitHub that internalize source control. I almost never see strikeout on Stack Exchange.

I am not opposed to it as a synonym for strikeout and del html tags, but it is not in the original Markdown definition doc for a reason, I think.

1 Like

but I am already used to GitHub flavoured markdown and probably many other people too.

Yes, amen to this! I sometimes find myself unconsciously writing with “tildthrough” text in e-mail or IM when purposefully identifying a crossed-out message.

A more common-place scenario where strikethrough is needed is proof reading. An issue I opened earlier shows a case where having a native strikethrough syntax makes sense, as opposed to just falling back on regular <s> tags:

# "Sorry, new users can only put 4 links in a post." Well, bite me.
1 Like

Probably I’ll suggest an extension to support out of box diffviews as



+1 I agree, and it could probably work similarly to emphasis parsing.

I’d like to see strikethrough formatting added, because it’s very useful for todo lists and project planning. I’m already using the <s> tag, but:

  1. It’s harder to eyeball-scan past the tag when reading a document, unlike e.g., ~~, which contains no letters
  2. I don’t feel as comfortable asking nontechnical friends to collaborate on project planning documents with me when they have to understand HTML tags.

Not one of the implementations pulled in in BabelMark translates the ~~word~~ syntax into an HTML <s> element (the <del> element type is an obvious alternative), and the majority of implementations don’t seem to recognize the syntax as anything special at all.

And by the way: How do you explain that ~~ should translate into <s> and not into <del> (and one would also need, for consistency, a syntax that translates into <ins> in that case)?

So in my point of view, I doubt that extending the CommonMark syntax in this direction is consistent with CommonMark’s stated goal of being “highly compatible” (although extending and not only refining the syntax has been done before, too), at least for now.

I for one would wish that QUOTATION MARK translates (under certain circumstances) into <q>, which is after all the “official” HTML element type to contain, well: inline quotations—but writing the tags literally into the text does achieve what I want anyway (with just one keystroke more), so I don’t see any urgency here. And the same applies for strike-through formatting, in my opinion.

Babelmarks does not configure some parser extentions.


~~ is de-facto standard on github, supported by pandoc and so on.

I’m new here, so my apologies if I offend anyone or any agendas.

I can see three separate lines of discussion here, all mixed together:

  1. Whether strikethrough is useful / used
  2. What strikethrough means
  3. How to represent it in text.

In my case: yes; deleted text (I can live without the ironic use); and ~~ seems to be an unambiguous representation widely (in my experience) used.

I use strikethrough a lot while developing (internal) documentation, principally to cross out bits that are wrong, but keep them visible so others will know they’re wrong or have changed. That’s largely a reaction to the lack of or poor quality of text “history” features in the tools I have to use. I’d like to have a button that shows / hides these changes. :wink:

This version of strikethrough would / should be stripped out before “publishing” (whatever that means in the circumstances).

As a final comment (and to stir the hornets nest) a major value of standard extensions is that all implementations of that extension (they’re optional not mandatory) would do it the same way. Saves both developer and user brain cells.