Whitespace in image paths... #503
Comments
|
If I understand correctly, whitespaces inside URLs enclosed by angular brackets have been disallowed recently to be more consistent with autolinks where they have never been allowed. Maybe a better solution would have been to require angular brackets inside autolinks to make whitespace allowed in its URL. This would of course result in double brackets: <http://absolute.url/with white space#nay>
<<http://absolute.url/with white space#yay>>
[a](http://absolute.url/with white space#nay)
[b](<http://absolute.url/with white space#yay>)
[c](relative.url/with white space#nay)
[d](<relative.url/with white space#yay>)and then perhaps also <relative.url#nay>
<<relative.url#yay>> |
|
If escaping spaces in link destination was allowed #493, there would be alternative solutions of course: <http://absolute.url/with\ white\ space#yay>
[e](http://absolute.url/with\ white\ space#yay)
[f](<http://absolute.url/with\ white\ space#yay>)
[g](relative.url/with\ white\ space#yay)
[h](<relative.url/with\ white\ space#yay>)As
|
|
Why are quotation marks not an option? It seems odd that a local file path link should conform to the standards of a url link. I think new users to markdown would be put off by not being able to include an image with a space in its name. |
[foo]("url/with white space")Quotation marks could be another option, but it would be a new syntax variant and could possibly be confused with a link title. Babelmark tells us that this would happen in Markdown.pl and some others that support link destinations being omitted. Angular brackets and backslash escape, on the other hand, are already part of the syntax and would just need some minor tinkering with to get a solution for this viable use case. |
|
What about just making it tolerate spaces? This is what pandoc, kramdown, and even markdown101 do (though not markdown102 for some reason). Babelmark In other words, whatever comes before the optional link title is the url, minus any trailing spaces. No extra delimiters or syntax needed. We could escape the spaces (like pandoc does) or not. I think we can still square this with autolinks not supporting spaces. Autolinks don't support alt text, or titles. If you need a basic short form link, you can use an autolink. If you need more flexibility, use a normal link. These would be all be valid |
|
Hi
I have a question about this. I don't understand this.
ÖMER SEYFETTİN AYDAR (ROHAN)
13 Oca 2018 14:23 tarihinde digitalMoksha <[email protected]> yazdı:
What about just making it tolerate spaces? This is what pandoc, kramdown, and even markdown101 do (though not markdown102 for some reason). Babelmark<https://babelmark.github.io/?text=!%5BAlt+text%5D%28imgs%2FTristachersee+pier.jpg+%22Tristachersee+Pier%22%29++%0A>
In other words, whatever comes before the optional link title is the url, minus any trailing spaces. No extra delimiters or syntax needed. We could escape the spaces (like pandoc does) or not.
I think we can still square this with autolinks not supporting spaces. Autolinks don't support alt text, or titles. If you need a basic short form link, you can use an autolink. If you need more flexibility, use a normal link.
These would be all be valid
![Alt text]("Tristachersee Pier")
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#503 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AMfFQf7LDzfNTZ2E6R1-xj0GMO-cip4Jks5tKJIhgaJpZM4PxVoP>.
|
|
@ph21ph currently, CommonMark does not support spaces in link urls. So generates because it doesn't recognize the space in the url. I'm suggesting that the parser considers the url to be everything from the This way we get a proper image/link: |
|
@digitalmoksha - the problem is that titles need not start with "; they can also be contained in single quotes or parentheses. So I think it's still a good idea to exclude spaces from regular link destinations. However, I'm convinced that it was a mistake in 0.24 to remove the ability to put spaces inside link destinations inside I'm for making the change to allow spaces inside |
++%0A){kind=link}
|
@jgm Thank you for making this change, it helps. It still seems to me though that the title requires some type of delineation - surrounding double quotes, single quotes, or parentheses. So wouldn't it still be possible to consider everything before the those delineators as the url? In any case, thanks for the fix! |
|
digitalMoksha <[email protected]> writes:
@jgm Thank you for making this change, it helps.
It still seems to me though that the title requires some type of delineation - surrounding double quotes, single quotes, or parentheses. So wouldn't it still be possible to consider everything before the those delineators as the url?
Well, one tricky thing is that the title can be in parentheses,
and parentheses can occur in URLs.
Actually, this is something we might want to revisit (and discuss
on talk.commonmark.org). I've never seen anyone use parens for a title,
but it is in John Gruber's original Markdown syntax description:
"optionally followed by a title attribute for the link, enclosed in
double or single quotes, or enclosed in parentheses."
Despite that, his own Markdown implementations don't support this
syntax, and neither do most others:
https://johnmacfarlane.net/babelmark2/?normalize=1&text=%5Bhi%5D(url+(title))%0A
So maybe we should consider dropping support for parenthesized titles.
This could still raise problems if URLs contain quotation marks,
I suppose.
|
|
I don’t think dropping title-in-parentheses would make sense nor fit the scope of this project. Anyway, I’ve said this before, syntax extensions will want to use other characters (that are legal inside an URL) after the link destination without requiring a title. This applies in particular to additional attributes for image links (or more generic embedded media), but different behavior for links with and without a leading exclamation mark [link to image][foo]
![embedded image][foo]
[foo]: foo.png "title"
[foo]: foo.svg "title before explicit size" =300*400
[foo]: foo.svg =300*400
[foo]: foo.svg "" =300*400
[foo]: foo.svg =300*400 "title after explicit size"
[foo]: foo.svg?lang=en =300*400
[foo]: <foo bar.svg> =300*400(There are deployed flavors of Markdown that support this or a similar syntax for explicit image dimensions.) |
I've opened this issue based on this discussion: https://talk.commonmark.org/t/whitespace-in-image-paths/1121/10
The issue for me is that now it’s much more difficult to add a reference to an image file on disk. It’s very common to have image names that have spaces in them (even macOS creates their screen shots named “Screen Shot 2017-08-05 at 11.07.11 AM.png” for example).
And while we could ask the user to replace each space with a ‘%20’, that seems excessive and unfriendly. I thought enclosing the url in pointy brackets was a workable, if not obscure, way of solving the problem ( I would have preferred to enclose the url in quotation marks, because I think that is more intuitive, but maybe conflicted in other situations).
I would also argue that the usage of Markdown for documents that are not intended to live on the internet is important, from writing your next book and including image/figures, to journaling, taking business notes, etc.
I’m not crazy about the original pointy bracket syntax:
I think using double/single quotes is much more intuitive and consistent with how we include the use of spaces in the title and other places:
However, I don't think the user should be forced to remember how to space-encode a filename. This is what is currently required:
The text was updated successfully, but these errors were encountered: