{"action":"created","issue":{"url":"https://api.github.com/repos/jgm/pandoc/issues/2761","repository_url":"https://api.github.com/repos/jgm/pandoc","labels_url":"https://api.github.com/repos/jgm/pandoc/issues/2761/labels{/name}","comments_url":"https://api.github.com/repos/jgm/pandoc/issues/2761/comments","events_url":"https://api.github.com/repos/jgm/pandoc/issues/2761/events","html_url":"https://github.com/jgm/pandoc/issues/2761","id":138971790,"number":2761,"title":"Improving Small Cap Syntax: Suggesting to Treat Small Cap as a New Level of Emphasis","user":{"login":"ickc","id":10970208,"avatar_url":"https://avatars.githubusercontent.com/u/10970208?v=3","gravatar_id":"","url":"https://api.github.com/users/ickc","html_url":"https://github.com/ickc","followers_url":"https://api.github.com/users/ickc/followers","following_url":"https://api.github.com/users/ickc/following{/other_user}","gists_url":"https://api.github.com/users/ickc/gists{/gist_id}","starred_url":"https://api.github.com/users/ickc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ickc/subscriptions","organizations_url":"https://api.github.com/users/ickc/orgs","repos_url":"https://api.github.com/users/ickc/repos","events_url":"https://api.github.com/users/ickc/events{/privacy}","received_events_url":"https://api.github.com/users/ickc/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":9,"created_at":"2016-03-07T12:54:11Z","updated_at":"2016-03-08T11:22:39Z","closed_at":null,"body":"I am sure people have been brainstorming and discussing about this. And a quick search showed that almost a decade ago this has been discussed and a syntax like `^^small cap^^` has been suggested but probably it is not attractive enough for people to pick it. In contrast I'm totally new here so probably what I'm going to say don't even worth 0.02 cents. But please bear with me:\r\n\r\nI think the more important thing than picking a syntax is the need to have one. Although it is difficult for people to agree on a syntax, I wish we can at least agree a need of a better syntax. In pandoc I think the small cap is the only exception to the rule that it does not look \"marked down\" but uses HTML syntax, although it understand it and will transform it according to the output format. Probably that makes it most urging to have a new, \"marked down\" syntax?\r\n\r\nI also understand because of the CommonMark movement, probably it's not the best time to define new syntax. But I think at least we should leave it as an open issue pending to be solved sometime in the future when the dust settled?\r\n\r\nAs to the suggestion of syntax, here's one: `!small cap!`. Seems like it shouldn't has a conflict on existing syntax yet. But it's just my naive suggestion. I think more importantly is we agree we need a better syntax for that."},"comment":{"url":"https://api.github.com/repos/jgm/pandoc/issues/comments/193736090","html_url":"https://github.com/jgm/pandoc/issues/2761#issuecomment-193736090","issue_url":"https://api.github.com/repos/jgm/pandoc/issues/2761","id":193736090,"user":{"login":"ickc","id":10970208,"avatar_url":"https://avatars.githubusercontent.com/u/10970208?v=3","gravatar_id":"","url":"https://api.github.com/users/ickc","html_url":"https://github.com/ickc","followers_url":"https://api.github.com/users/ickc/followers","following_url":"https://api.github.com/users/ickc/following{/other_user}","gists_url":"https://api.github.com/users/ickc/gists{/gist_id}","starred_url":"https://api.github.com/users/ickc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ickc/subscriptions","organizations_url":"https://api.github.com/users/ickc/orgs","repos_url":"https://api.github.com/users/ickc/repos","events_url":"https://api.github.com/users/ickc/events{/privacy}","received_events_url":"https://api.github.com/users/ickc/received_events","type":"User","site_admin":false},"created_at":"2016-03-08T11:22:39Z","updated_at":"2016-03-08T11:22:39Z","body":"# Using Nested Emphasis as a Test on How Current Implementations of Markdown Treated `*`s #\r\n\r\nAs we have discussed `*`, `**`, `***` should be viewed as different levels of emphasis, not styling (although styling is used to represent the meaning). Then one natural way of testing the idea is emphasis within emphasis, or nested emphasis. For example, in LaTeX when emphasis within emphasis occurs, opposite font style is used to emphasize the inner emphasis. *Example is* this emphasis *here*. Since the whole sentence is italic, the normal \"this emphasis\" becomes emphasized. Similarly, in Markdown one would expect `*Example is *this emphasis* here*` would be rendered as \"*Example is* this emphasis *here*\".\r\n\r\nI ran a test in Babelmark 2, and found out that pandoc does not behave this way. And to my surprise CommonMark does not \"get it right\" either. Because the issue involved is about markdown in general, so I posted it in the CommonMark Discourse. But I think it is worth mentioning here since this finding seems to show that **we are not taking `*`s in Markdown as much as emphasis as we think**.\r\n\r\nOrigin text posted in [Issues to resolve before 1.0 release - Spec - CommonMark Discussion](http://talk.commonmark.org/t/issues-to-resolve-before-1-0-release/1287/28):\r\n\r\n> # Testing Nested Emphasis\r\n> \r\n> It is similar to [Nested emph and strong](http://johnmacfarlane.net/babelmark2/?normalize=1&text=***bold**+in+ital*%0A%0A***ital*+in+bold**) in Babelmark 2, but more exhaustive:\r\n> \r\n> ```Markdown\r\n> - 1 in 1: *some text *emphasized* again*\r\n> \r\n> - 1 in 2: **some text *emphasized* again**\r\n> \r\n> - 1 in 3: ***some text *emphasized* again***\r\n> \r\n> - 2 in 1: *some text **emphasized** again*\r\n> \r\n> - 2 in 2: **some text **emphasized** again**\r\n> \r\n> - 2 in 3: ***some text **emphasized** again***\r\n> \r\n> - 3 in 1: *some text ***emphasized*** again*\r\n> \r\n> - 3 in 2: **some text ***emphasized*** again**\r\n> \r\n> - 3 in 3: ***some text ***emphasized*** again***\r\n> ```\r\n> \r\n> # Results\r\n> \r\n> See [Babelmark 2 - Compare markdown implementations](http://johnmacfarlane.net/babelmark2/?normalize=1&text=-+1+in+1%3A+*some+text+*emphasized*+again*%0A%0A-+1+in+2%3A+**some+text+*emphasized*+again**%0A%0A-+1+in+3%3A+***some+text+*emphasized*+again***%0A%0A-+2+in+1%3A+*some+text+**emphasized**+again*%0A%0A-+2+in+2%3A+**some+text+**emphasized**+again**%0A%0A-+2+in+3%3A+***some+text+**emphasized**+again***%0A%0A-+3+in+1%3A+*some+text+***emphasized***+again*%0A%0A-+3+in+2%3A+**some+text+***emphasized***+again**%0A%0A-+3+in+3%3A+***some+text+***emphasized***+again***%0A)\r\n> \r\n> About the results:\r\n> \r\n> - IMO as long as there's some asterisks in the rendering, it is wrong.\r\n> - Those that do not include any asterisk in the results can be categorized in:\r\n> \t- commonmark 0.24.0 and others\r\n> \t\t- It is interesting to see the lastest CommonMark treated emphasis almost as styling, in \"1 in 1\", \"2 in 2\" and \"3 in 3\", the inner emphasis hasn't been emphasized from the surround text.\r\n> \t- RDiscount 1.6.8 and others\r\n> \t\t- The 2 nesting levels are treated as addition first and if it exceeds 3, it becomes a difference between the 2.\r\n> \t- cebe/markdown GFM 1.1.0 and others\r\n> \t\t- \"2 in 3\" inner wordings are not emphasized.\r\n> \r\n> So the only one \"get it right\" (treating emphasis between emphasis as another emphasis within the surrounding texts) is RDiscount 1.6.8 (and s9e\\TextFormatter (Fatdown/PHP)).\r\n> \r\n> It seems no one is discussing this here. But to me CommonMark's interpretation seems wrong, and RDiscount (and the other one)'s are the correct one. Should this be added to [Issues to resolve before 1.0 release](http://talk.commonmark.org/t/issues-to-resolve-before-1-0-release/1287)?"}}