-
-
Notifications
You must be signed in to change notification settings - Fork 11.2k
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
Add support for anchor links #93
Comments
Can probably be done by hacking this line in |
I took a look at this and... it's not as easy as I'd hoped (mostly because I hadn't thought it through properly). First of all, the So, anchor link --> anchor target is certainly doable, if a little dirty. The bigger problem is the usability of it. The simplest thing to do would be to rely on what Marked is already doing to transform (let's say slugify) the header text when adding IDs -- it's lowercasing and replacing adjacent non-alphanumerics ( [Jump to where my header is sweet](#my-header-sweet-yes-experts-tell-us)
...
## My Header: Sweet? Yes -- experts tell us
... That workflow isn't terrible, but it means that users have to mentally do the slugification in order to create their anchor links. That's not easy for everyone. And it's complicated by another unfortunate thing: It's not possible to test your anchor links. At least not in Gmail -- if you click a rendered anchor link, you get Gmail's little link-editor box pop up, and if you then click the "go to link" link it opens a new tab with your Gmail inbox (technically, it opens a new tab with Well, that's a bad combination: a difficult-to-guess slugification combined with an inability to (reasonably) test your guess. @caseywatts foresaw this when he first requested the feature (and I subsequently, foolishly, didn't fully appreciate this):
I didn't, and don't, really like this, since it's a (/another) deviation from the Markdown spec (and the HTML spec, kinda). Spaces are valid characters in links but they have to be escaped ( If we made this change, it would break this (entirely valid MD, which someone might be writing right now): [jump 1](#MyJumpy)
...
<a href="#" name="MyJumpy"></a>
...
[jump 2](#Another Jump)
...
<a href="#" name="Another Jump"></a> Because, with the change, it would render to this: <a href="#myjumpy">jump 1</a>
...
<a href="#" name="MyJumpy"></a>
...
<a href="#another-jump">jump 2</a>
...
<a href="#" name="Another Jump"></a> ...which breaks the anchor links. (However, if the jumps go to headers and the anchor links used the exact text of the headers, then it would work, because they'd get slugified the same. But I don't think that's likely enough to save us.) What to do? It could be made optional. There's nothing wrong with this, but I don't really like it. I think it'll be difficult to coherently describe to the user what the option does. And it seems like a usability cop-out. But it can be done. (Default on? Default off?) Or we could just make the change and let people complain if it causes them a problem. I'm leaning towards this. I'd appreciate any input anyone might have. I'm going to let this simmer for a little bit. |
Implemented in 83aa9c4. Will be in the next release (which will be soon). @caseywatts: If you can try it out, please do. Thanks. |
I'm so excited for this! ^_^ I'll gladly test it out, thanks!
|
See discussion here: https://groups.google.com/forum/?fromgroups=#!topic/markdown-here/eaq1JoNhyws
The text was updated successfully, but these errors were encountered: