Spaces in image path creating incorrect image source and title

[facelessuser]

It appears that when given an image ![alt](a b.txt) that Python Markdown will create an element <img alt="alt" src="a" title="b.txt" />. I was reading the Markdown spec, and it states that titles should be enclosed in quotes: http://daringfireball.net/projects/markdown/syntax#img.

While I am not sure if the spaces should or should not be allowed in an image path, I get the impression that Python Markdown in this case should not be grabbing b.txt for the title as it is not enclosed in quotes.

[waylan]

I can't deny that the rules are unambiguous about this. The Babelmark results are interesting. It would seem that most Markdown parsers don't even see that as an image. In other words, you can't have a space in an image URL anyway.

Although, comparing with spaces in links there seems to be quite a bit of inconsistency. It is not clear to me what the actual output should be.

This may be one of those situations were the output is simply not what the author expected, which should be a signal that the author got the syntax wrong. I suppose the easiest way to signal that, is to simply not even recognize it as Markdown syntax at all (output <p>![alt](a b.txt)</p>), which seems to be popular among many implementations.

[facelessuser]

Results are quite different when I use png extension: http://johnmacfarlane.net/babelmark2/?text=!%5Balt%5D(a+b.png). Not sure why I chose txt in the example...

Anyways, whether space is or is not allowed, I do find the title handling odd as Python Markdown is the only to turn the non quoted second word into a title: http://johnmacfarlane.net/babelmark2/?text=!%5Balt%5D(ab.png+title).

[waylan]

Funny, I missed that you used the txt file extension. Anyway, this is clearly a bug. The question is, do we want to be strict old-school and fail to recognize it as image syntax at all (return <p>![alt](a b.png)</p>) or take a more modern approach (<p><img src="a%20b.png" alt="alt"></p>)?

Modern OSs support file names with spaces and they are likely to be encountered in the real word (which was not nessecarily the case when Markdown was first created). However, spaces make for not-so-readable URLs and I'm generally against them in URLs. Therefore, I'm inclined to stick with the old-school majority on this.

[facelessuser]

I never personally use spaces. This was actually brought to my attention by someone else, so old school is fine with me. I'll try and patch the title issue soon though via a pull.

[facelessuser]

@waylan are you planning to enforce no spaces in traditional links as well? I was just thinking, currently this is not enforced in either images and links. I'm not sure how many people have been using Python Markdown with spaces in links and images. I imagine there may be some breakages when "fixing" this. I just want to make sure I have clear directions before I patch this via a pull.

[text](url/with/no/spaces "title")

[facelessuser]

I just confirmed that spaces in links work, so I would be removing that support if you give me the go ahead.

[waylan]

Let's leave links alone. As you observe, that could break existing documents. Whereas it didn't work before for images, so we won't be breaking anything that wasn't already broken.