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 http://www.reddit.com/r/LightWeightMarkup/wiki/commonmark/unofficialextensions 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 http://johnmacfarlane.net/pandoc/README.html 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.
2 Likes
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
+++ 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.
4 Likes
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.
https://github.com/michelf/mdtest/issues/7
1 Like
Probably I’ll suggest an extension to support out of box diffviews as
>+
>-
>
2 Likes
+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:
- It’s harder to eyeball-scan past the tag when reading a document, unlike e.g.,
~~, which contains no letters - I don’t feel as comfortable asking nontechnical friends to collaborate on project planning documents with me when they have to understand HTML tags.