Strikeout threw out? Strikethrough strikes out, throughout?


The original intent was to give a specification of core Markdown elements. Certainly extensions like strikethrough can be considered later, but I’d like to get the core settled first.



That sounds like a relatively logical approach, professor. I just thought I’d get this one up on the board: it and other extensions can be resolved as future contingents.



Also, I’d point out that the discussion above regarding <s> vs. <del> is exactly why I think its important to be explicit about targeting HTML5.



Aye, hence I’ve created two threads to cover both the “presentational” <s> and the editorial review/diff style of tags like <del>.

##Strike Through:

Via --strike through--

Is covered in this thread

Usually rendered purely as a strike through . So semantically doesn’t always mean incorrect information, it can mean an ironic statement.

##Strike Out:

Via >>~~ strikeout ~~<<

Is covered in this thread

<del> might be rendered in some site as [ --- striked out --- ]
(As for <ins> it might looks like [ +++ insert +++ ] via >>++ insert ++<<)

Edit: modified >>-- strike through --<< to -- strike through --. And added to strikeout

1 Like


There is no reason srikethrough shouldn’t be a core feature of markdown. There is nothing to discuss. Every markdown implementation that implements srikethrough, does it the same way. When (not if) you add srikethrough to the standard, you are going to specify that two tildes get parsed into a <del>; anything else would be unwise.


  • there is minimal extra cost involved in adding srikethrough to the standard now.
  • by delaying to add it, you gain nothing.
  • by adding it you would make a lot of people happy.
  • what exactly is your problem here?


Tone down the rhetoric please; see

The initial goal of CommonMark is to stabilize the existing Markdown spec, not adding everyone’s pet extensions.

Over time, once the much more important work of stabilizing the spec and having a great set of tests for the spec is complete, we will look at extensions and additions. But that is not the priority over the next immediate 6 months.


Tables in pure Markdown
What could a "spoiler tag" extension look like?

If you need to support strikethrough right now, no one is stopping you from implementing it (via the ~~ syntax which GitHub uses, or via plain HTML). You may need to convert some Markdown documents later if a different syntax is chosen, although this seems unlikely.

I would much rather see the CommonMark core remaining small. App writers then have a choice as to which additional features they will support. They can clearly inform users of which extensions are supported.

1 Like


That was the toned down version :p

I just don’t see strikethrough as ‘big’ or controversial enough to omit from the core standard. There is already a de facto standard for it, and lots of existing markdown that uses it. It seems as if there is a feeling that not adding something to the spec is always easier than adding it, but what I’m trying to say is that sometimes poor decisions made early on can cost a lot more further along in the project’s lifetime.

As a user, when I google for ‘markdown strikethrough’ and find something that seems to suggest that two tildes will delete text, then try to use it and it fails, it really frustrates me. I am suggesting that you should try to channel that kind of antipathy towards specific markdown implementations for failing to conform to the spec, rather than towards CommonMark for failing to conform to people’s expectations.



There’s a line drawing problem. If strikethrough is added to the core, why not cite, mark, spoilers, tables, etc as well? The line has to be drawn somewhere, and it appears to have been drawn at “features found in John Gruber’s Markdown” (where fenced code blocks are counted as the same type of feature as whitespace codeblocks). A lot of work has already gone into working out a solid spec for just these features. It would take even more time if everyone’s favourite feature was also included.

That is a decision of the app developer, not the spec writer. Even for features included the core, the developer may still choose to exclude them. For example, as a developer I sometimes disallow images and headings because I want to ensure that the writer only uses a minimal set of tags. If you’re frustrated, you should ask the app developer to enable your desired feature.



I think they should be decided on a case by case basis. For each of the other extensions you mentioned there are real pros and cons to consider, and their absence from an implementation or core spec is understandable. Meanwhile, the only argument I have seen against strikethrough is that John Gruber didn’t like it.



The main argument for strikethrough appears to be that people do like/want to use it. Just as people like other features (tables in particular) and want those features included in the core. It’s all quite subjective and varies based on the writer’s needs.

At least by drawing the line at the features in Gruber’s spec we have a line.

1 Like


Strikethrough already has a widely adopted standard format. The reason that double tilde strikethrough should be in the standard is because it already is standard, and the point of having a standard is to specify the standards that are standard.

1 Like


note again that I proposed that strikethrough is --strike through-- and strikeout is >>~~ strikeout ~~<< ( uses >><< to safely allow for striking out trailing spaces.)

This is since they have distinct semantic meaning. Strikeout is more of a critic’s markup Reviewing Markups

Since core spec is not going to be updated in a while. An unofficial extention spec might be handy in to keep everyone in the same page.



[quote=“Buddy, post:31, topic:820”]
The reason that double tilde strikethrough should be in the standard is because it already is standard, and the point of having a standard is to specify the standards that are standard.[/quote]

@codinghorror and @jgm have already stated that the intent of this particular standard is to give a specification of core Markdown elements. Not all standards need to codify every element in wide use. In this case, that’s what the extensions will be for.

In practical terms (for writers), is there a difference whether a feature in part of the core or an extension? App developers will either implement support for an element or they won’t. This is independent from whether the element is part of the core or if it is part of an extension. So long as the element is included (one way or another) in CommonMark is there a problem?



I’m looking at the W3C HTML5 spec now and there’s no mention of either strikethrough or strikeout by those terms.

That there’s a distinction between <s> and <del> is a good observation though.

There is a wide use of ~~ but it is unclear whether this should be used for <s> or <del>. GitHub calls the use of ~~ strikethrough, but the HTML element generated by GitHub Flavored Markdown is <del>. The <s> element may be more suitable for their intent as it “represents contents that are no longer accurate or no longer relevant.” whereas <del> “represents a removal from the document.”. But the GFM spec is not clear what the indented use of “strikethrough” is.

What other flavours include the ~~ syntax? I couldn’t find it in Markdown Extra. Pandoc calls it “Strikeout” and generates the <del> element. iA Writer converts ~~ to <del> as well. MultiMarkdown does not include ~~ but includes {~~text~~} syntax for deletion known as “critic markup”.

1 Like


well judging from what you told me. ~~ is for <del> and -- is for <s>.

The biggest difference is that pandoc thinks that trailing whitespace for <del> is not an issue thus

This ~~is deleted text.~~

but if trailing whitespace is an issue then, for <del> one of these may do.

This  {~~  is deleted text.   ~~}
This >>~~  is deleted text.   ~~<<
This  [~~  is deleted text.   ~~]
This  /~~  is deleted text.   ~~/
This  [~~  is deleted text.   ~~]

This critic markup style is most important for document editing of books etc… where number of spaces may count.

As usual, strikethrough doesn’t really worry itself about trailing spaces thus --strikethrough--



The ~~ syntax appears to work similar to *emphasis* where whitespace on either side deemphasises the text. For reviewing markup it is probably best to at least support the MultiMarkdown syntax or something similar as well (as we have been discussing in the reviewing markup topic) to avoid the whitespace issue. But reviewing markup is a separate topic and is best not spilled over into this topic.

Using -- for <s> is going to clash if there is an en-dash extension (see Pandoc’s smart punctuation for reference). I think we should avoid using -- for strikethrough/strikeout for this reason.

I’m in favour of using ~~ to represent “strikethrough” as this syntax is already widely used and looks like strikethrough/strikeout text. The question is what element should this syntax map to: <s> or <del>?



shouldn’t be too bad. I read and think that as long as you disallow spaces in dashes for strikethrough, and enforce dashes for smart en-dashes. There should not be any conflict.

en-dashes (notice spacing):

This is a statement -- with another concept here

strike through (notice lack of spacing):

This is a statement --with this statement removed--



Note that en-dashes are recommended in numerical ranges: 45--47. In such uses you definitely don’t want space around them.



One hesitation I’d have about supporting ~~strikeout~~ (as in pandoc and some other flavors) is that it might be better to handle this kind of thing as Critic Markup does.

I’ve had some reservations about some aspects of Critic Markup (these are discussed at great length in the pandoc-discuss list), but I do like the explicit grouping with {.

I don’t see much risk of clashing with a {} attribute syntax, since in Critic Markdown the first character after the { will always be non-alphanumeric.



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?

1 Like