New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Space after opening tilde fence before info string #537
Comments
That's a good point about the strikeout extensions. I
don't know which would be better:
1. Disallow tildes in info strings after a tilde fence.
2. Require a space after the tilde fence.
I think I prefer 1. This would make the two kinds of
fence entirely symmetrical. But it rules out the pretty
~~~ ruby ~~~~
code
~~~~~~~~~~~~~
Anyone have thoughts about this?
|
Although I proposed and still prefer option 2, I assume that less existing content has problems with option 1. Weaker variants of option 1 would be to disallow a) the exact number or b) more than the number of consecutive tildes as in the fence to appear in the info string. ~~~stricken~~~
no code block
~~~
~~~ not-stricken ~~~
no code block
~~~
~~~perhaps-stricken~~~~~
code block according to a) but not b)
~~~
~~~not-stricken~~ ~ ~~
code block
~~~ PS: Github's fork of github/cmark-gfm#71
|
Although GitHub's implementation allows any number of
(and unbalanced) tildes for strikethrough, their
spec specifies exactly two tildes on each side.
That wouldn't pose a problem for the current behavior
of tilde code blocks, even with no extra space.
In
~~~~lua~~~~
the code fence interpretation would take precedence
over the nested strikethrough interpretation, but I
think that's fine and appropriate.
Note that there's also an option 3, which is to impose
some tighter restriction on info strings that is
uniform across types of code blocks. E.g., pandoc
allows either a single word or an attribute block
of form `{.class .class2 id=foo key="value"}`.
|
JFTR, the quirk in cmark-gfm has been fixed. github/cmark-gfm#120 |
JFTR, v0.29 settles the related issue of initial and final whitespace in code spans. |
This prose does not say anything about whether whitespace is required between the backticks or tildes and the info string, just that they are trimmed away eventually. There is an example further down that begins with
```ruby
, though. Apparently, whitespace is optional in backtick fences and presumably also in tilde fences.The rules for backticks inside the info string are there because of the necessary but peculiar rules for inline code spans marked with one or many backticks: They can use any matching number of backticks and may be flanked by whitespace on the inner side, the trimming rules for which are still debated.
Tildes are not used for inline markdown in vanilla Commonmark, but they are used in extensions, usually either for subscripts or strike-through / deletion or for both. Github Flavored Markdown, for instance, supports stricken text with any matching number of tildes before and after (but no whitespace is allowed between the markers and the marked-up content). Although I believe they should limit that to two tildes (like Gitlab does), this makes some lines that start with three or more tildes ambiguous. A simple fix would be to require whitespace before the info string in a tilde code fence.
Even if a flavor uses exactly two tildes before and after stricken text, it may also use single tildes before and after subscript text, which can be combined for three consecutive tildes.
PS: That ruby example also expects
code="language-ruby"
in HTML output, which is not clearly marked as merely an informative suggestion.PPS: I think, for consistency and readability, there should be a should (not must) requirement for heading underlines to also contain at least three uninterrupted equal signs
=
or hyphens-
. Thematic breaks have it, too, although they can be interrupted by spaces.The text was updated successfully, but these errors were encountered: