I’ve noticed several times on github, that when i give inline examples of strings, multiple spaces are eaten visually. AFAIK, this can’t be fixed with CSS. Is it useful to interleave >1 of spaces with ?
Now:
`foo bar` -> `foo bar`
Proposed:
`foo bar` -> `foo bar`
Also, we could replace single space with nbsp, to make inline code visible:
` ` -> ` `
Or this should be done by typorgapher extension?
Hm… i could preserve spaces with { white-spaces: pre-wrap } style, but found example 257.
What is the reason to eat spaces in parser? IMHO, if i use backticks, i know exactly what i “quote”, and my intention is to show string exactly as it is.
I thought of using non-breaking spaces, but this breaks cut-and-paste (since a nbsp is a different character than a regular space). Using CSS is the right approach. In other output formats (e.g. LaTeX) something else would need to be done.
We could reconsider about collapsing adjacent spaces. Any thoughts on this?
I don’t understand at all, why it’s considered normal to hide spaces of inline code blocks. May be, that was problem of ancient browsers. But i don’t understand practical use for it.
Does anyone know? I use inline backticks only to show code portions or string constants. Dropping spaces for such cases looks very bad idea. At least, i never needed that. And i remember many times, when my postings become “broken” on github.
+++ vitaly [Mar 05 15 17:48 ]:
[1]vitaly
March 5I don’t understand at all, why it’s considered normal to hide spaces of
inline code blocks. May be, that was problem of ancient browsers. But i
don’t understand practical use for it.
Pandoc doesn’t collapse internal space, and includes the following in the default HTML template header:
<style type="text/css">code{white-space: pre;}</style>
I think that is probably the right path. I know I considered this when writing the spec for inline code, but I can’t quite reconstruct why I preferred the collapsing behavior.
Collapsing of internal spaces should not be done if they are within a string literal, for example var a = " " // two spaces should stay the same. But that is not possible to implement considering the multitude of possible languages so they should be left alone always.
I suppose that removing leading and trailing spaces does make sense though.
I suppose that removing leading and trailing spaces does make sense though.
This depends on the context. When I type a trailing space in an inline code block (example of that — search for “note the space character at the end”), it’s there for a reason, and I don’t want my Markdown parser to remove it.
Please don’t collapse or trim spaces.
+++ mathias [Mar 12 15 09:12 ]:
[1]mathias
March 12I suppose that removing leading and trailing spaces does make sense though.This depends on the context. When I type a trailing space in an inline
code block ([2]example of that — search for “note the space character
at the end”), it’s there for a reason, and I don’t want my Markdown
parser to remove it.Please don’t collapse or trim spaces.
A leading and trailing space have to be removed, because of
the way Markdown inline code quoting works. Suppose you
want to quote a single backtick character. Then you do it
like this:
`` ` ``
Note, you have to leave a space between the opening sequence
of backticks and the contents, and between the contents and
the closing sequence, or you just get
which is nothing.
That's the motivation for stripping leading and trailing
backspace. The spaces in the example above are not part of
the content.
One possibility that would allow for leading/trailing
space in the content would be to strip at most *one*
leading or trailing space.
Indeed, that is suggested by Gruber's Markdown documentation,
which says:
> The backtick delimiters surrounding a code span may include spaces
> — one after the opening, one before the closing. This allows you
> to place literal backtick characters at the beginning or end of a
> code span.
However, his implementation, Markdown.pl, strips ALL the leading
and trailing whitespace.I think, we could make more strict rule - trim 1 space only if content begins with “spaces + backtick” or ends with “backtick + spaces”. In other cases trimming is not needed.
That seems to be enougth to solbe special case, when you need ` in inline code.
+++ vitaly [Mar 12 15 16:48 ]:
[1]vitaly
March 12I think, we could make more strict rule - trim 1 space only if content
begins with “spaces + backtick” or ends with “backtick + spaces”. In
other cases trimming is not needed.That seems to be enougth to solbe special case, when you need ` in
inline code.
That would work, but I’m concerned about making the rule
more complicated than necessary. (Cognitive load for users,
surprise at the fact that a leading space is sometimes kept
and sometimes not.) Always stripping at most one leading +
trailing space seems more straightforward and easier to
remember.
Easy to remember, but less convenient to use. I guess, ` almost never used. I don’t find nice to force users add space everytime because of rare and useless exclusion.
+++ vitaly [Mar 12 15 18:16 ]:
[1]vitaly
March 12
jgm:Always stripping at most one leading + trailing space seems more straightforward and easier to remember.Easy to remember, but less convenient to use. I guess, ` almost never
used. I don’t find nice to force users add space everytime because of
rare and useless exclusion.
They’re not forced to use a space. Rather, if they do use a space after the opening delimiter or before the closing, it will be stripped off. That has the advantage of being uniform and regular, and also of conforming to the letter of John Gruber’s Markdown syntax description, thus maximizing backwards compatibility.
I understand. I mean, when leading | tailing spaces needed, it’s not convenient to remember increment spaces count. The same about backward comatibility - for this case it doesn’t worth to make markup less human friendly.
Combination of spaces + backtic in code is extremely rare exclution, and i think it’s not good idea to propagate it’s logic for more often cases. It’s natural, when i see exactly what i type in backitcks, when i need spaces at the start or at the end…
+++ vitaly [Mar 12 15 20:11 ]:
[1]vitaly
March 12I understand. I mean, when leading | tailing spaces needed, it’s not
convenient to remember increment spaces count. The same about backward
comatibility - for this case it doesn’t worth to make markup less human
friendly.Combination of spaces + backtic in code is extremely rare exclution,
and i think it’s not good idea to propagate it’s logic for more often
cases. It’s natural, when i see exactly what i type in backitcks, when
i need spaces at the start or at the end…
Including inline code with leading or trailing spaces is
also pretty rare, I’d guess. Most people aren’t going to use
spaces between the backticks and the contents, so it won’t
matter for them what is decided on this issue.
My worry about your proposal is that if we include the
leading and trailing space in inline code in examples like
this,
` a `
we will (a) go against an explicit statement in Gruber’s
Markdown syntax description, and (b) possibly break existing
Markdown documents. That’s why I think there’s a strong
presumption for a more minimal change here.
@jgm I would like to resurrect this question, about collapsing whitespace in an inline code span. To me, the fact of even calling it a code span means the text inside there should be left alone.
From CommonMark Spec
Q: Why not just leave the spaces, since browsers will collapse them anyway? A: Because we might be targeting a non-HTML format, and we shouldn’t rely on HTML-specific rendering assumptions.
This seems exactly the reason you don’t want to collapse the spaces. HTML happens to do it for you, unless you use CSS to override it. Any other output format can display it as they wish - collapsed or not collapsed. Removing the spaces makes an assumption about the output format that they want the spaces removed.
From Gruber:
Unlike a pre-formatted code block, a code span indicates code within a normal paragraph.
The intent of the code span is similar to the code block, and should have most of the same characteristics. I think allowing consecutive spaces should be one of them. Removing the leading/trailing space is ok I think.
The change was made in the spec quite a while ago (though it is not yet in a released version of the spec). See https://github.com/commonmark/commonmark/issues/532
Thanks @jgm - totally missed the closed issue. Awesome. I’m also interested in a new spec release to see this change implemented downstream.