This value may be shown to the user, but it is primarily intended for private use.
As it can be shown to the user, why not always use <del> instead of <s>? More importantly for us, why should Markdown support both? If there is no practical reason, I suggest only supporting <del> via ~~ and saving a lot of confusion.
I may be mistaken, but <s> feels like a legacy element in the same way that <b>, <i>, and <u> do.
With CSS normally, if it’s presentational information only. In HTML5 they have been updated with semantic meaning, but it’s misleading coming from HTML4. This article explains the new meanings of <b> and <i>.
<del> would commonly be used to markup text that is no longer correct (otherwise why edit it out?). It might be removed for other reasons as well of course. Practically, the meanings of <del> and <s> seem close enough not to warrant a separate tag.
I think on closer reading, there is a distinct difference. The <del> tag is specifically a ‘reviewing’ tag, which means it is a tag that along with <ins> is for addition and subtraction of a content under review. This is much different than <s> which is for marking strikethrough of text, (rather than striking out), and thus is for public consumption. Refer to Reviewing Markups for more information.
<del> appears to encompass the meaning of <s> since it can be publicly presented as well. We need some examples of where <s> might be used but where <del> would be inappropriate. If there are no examples, perhaps <s> is not needed in Markdown.
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.
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.
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.
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.
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.