Based on http://criticmarkup.com/ . {} is already used in consistent attributes, so need a different delimiter that is easy to type.
This is a markup syntax, that is designed specifically for reviewing a document as a critic. In html this is usally via <del> and <ins>, not <s>. This is since the del tag means “Striking Out Text”, while the ‘s’ tag means “Striking Though” text.
It’s likely in real world usage, that strikeout text would show as a red highlighted text with --- on each end, as opposed to <s> which would show up as a normal strikeout. Additions is shown as a green highlighted text that has +++ on each end
Usually if such html document is to be published for public consumption, the <del> and <ins> tag will be removed. (e.g. These tags are likely to be seen in history view in wikipedia I guess)
#Proposed syntax:
inline
>>~~deleted text~~<< using <del>
>>~~deleted text~~++added text++<< using <del> and <ins>
>>++inserted text++<< using <ins>
Purpose of >><< is to safely allow for trailing whitespaces E.g. >>~~ trailing whitespace ~~<<
Regarding (3), I would use a version control system such as Git instead. This Git commit is for a Markdown file, for example. It is rendered sensibly on GitHub without the need for additional Markdown syntax.
If there is a html tag that corresponds, then use that. Else assign a CSS class to it in a consistent manner.
What would the rendered output look like?
Looks like how histograms in discourse looks like. E.g. strikelines. Or green + signs, on each sides. All depends on css implementation, but we should provide a default css template anyway.
Is there a simpler approach?
Just saw in another post that ‘triple character’ method might be more intuative and ‘markdowish’.
---striked out text---
+++Add this text in+++
~~~ Old Text ~~~> New Text ~~~
||| Highlight this text |||
___ underline this text ___
Regarding (3), I would use a version control system such as Git instead. This Git commit1 is for a Markdown file, for example. It is rendered sensibly on GitHub without the need for additional Markdown syntax.
Git is not always an option for everyone. What made markdown popular is that it is non technical. Also these usage may occur in an email context. People might appreciate being able to get these corrections over email in a quick and timely manner using this lightweight markup method. E.g. a paragraph for an abstract in a corporate report.
Oh and good thing about this? No need to set-up infrastructure like git installation, so less things to break.
<ins> and <del> appear to be the correct elements for this.
If ~~ is converted to <del> it could be used here. Whatever is decided on should be simple and intuitive. Have ++ and -- been considered? -- might conflict with line breaks, but ++ seems okay.
I suggest ~~ for <del> and ++ for <ins> (if they do not conflict) as they’re simpler. It seems ~~ is already used for <del> in some implementations, so it makes sense to stick with that syntax and it looks similar to -- visually. ++ uses the same number of characters as ~~, complementing it.
I understand the semantic now. Well since this is only about revision. We shall only cover <del> and <ins> not <s> which represents ‘revised information to be published to public via strikeout mark’. The reviewing markups is for internal review within an organization. So most likely these things should be kept as an extension, but still defined and supported (so we can ensure everyone who uses it will speak it consistently)
~~deleted text~~ using <del>
~~deleted text~~>added text~~ using <del> and <ins>
++inserted text++ and <ins>
So… what would a 'non review mark` look like? That is a question for
I would like to review my earlier comment about ~~this text is deleted~~ being used for <del>. It actually makes more sense to use -- since minus is the opposite of plus and ++ is the proposed <ins> syntax. ~~ could then be freed up for <s>. I don’t think -- would clash with horizontal rules since these must be at least three characters long. Unordered list items are one character wide, so no conflict there. There is the danger of conflicting with em dashes and en dashes however, so we should consider these.
I would counter that -- is better used for strike through.
Also I have another concern. What if you want to delete a space. e.g. ~~ this has a trailing space~~. This can get dangerous. In fact, I think that while --strike though-- could do without >><< , reviewing markups would be safer for parser with >><< like
>>--remove this sentence with a trailing space --<<
>>++ add this sentence and also a space on both sides ++<<
You raise a good point about preceding whitespace. This could be common when reviewing text. Maybe the {++inserted text++} and {--deleted text--} syntax from MultiMarkdown would be suitable. Or with spaces if need be {++ inserted text ++} and {-- deleted text --}. The curly brackets feel less harsh on the eyes than the backwards angle brackets to me. But maybe review text should stand out if it is temporary.
I want to avoid {} since it should be reserved only for consistent attribute syntax. And yes, it should stand out, since it’s something that is under review. And you really don’t want it getting accidentally published.
It might not be a problem if the consistent attribute syntax never begins or ends with ++ or --. We should investigate that before ruling out the MultiMarkdown syntax at least.
true about