Is it possible to target="_blank" in Hugo without resorting to inline HTML?
Dontāt think so.
But this is a question better asked to https://github.com/russross/blackfriday - the Markdown engine in Hugo.
Hi @TheLoneCuber,
There is also an interesting answer on StackOverflow to automatically add target="_blank"
to external links with JavaScript:
The only way I found is to use HTML (Iām not happy with that but this is the only solution). Or you can do what @anthonyfok suggests to you, using javascript even if it looks worst to me (my 2 cents)
You could also use a shortcode, but I think this is probably overkill.
The right answer here is to use HTML.
Markdown is intentionally simplistic. It gives you very little control over how things are rendered. However Markdown + Hugo gives you two great things to allow you the control you want. HTML is valid markdown, so you can use that if you want more control. Additionally Hugo provides shortcodes to provide even more powerful functionality inside of posts.
I tried this solution by the past but it wasnāt a good thing to do, I figured out when I wanted to move my contents (in markdown) to another static page generator. I had to redevelop the url plugin to interpret what was that code in my content. Breaking the simplicity of creating an url break the possibility to switch easily of solution.
Probably off-topic here, but something to look forward to when Hugo supports .adoc
, i.e. AsciiDoc (either via the @VonCās asciidocgo Go library or external Asciidoctor), which has a shorthand for target="_blank"
:
http://asciidoctor.org/docs/asciidoc-writers-guide/#target-window-and-role-attributes-for-links
I clearly need to look into shortcodes because I havenāt [yet]. They sound handy.
I made a quick custom Blackfriday renderer to test ācustom linksā:
Works fine - but Iām not sure if itās a good idea in real life and how it should be set up (only for external links?) ā¦
Hi all,
It would be fantastic if the custom blackfriday rendering could automatically be hooked up a shortcode provided by a theme or by the site itself (see GitHub issue 836). That is, if there is a template in either of:
/layouts/shortcodes/link.html
/themes/THEME/layouts/shortcodes/link.html
then that template could be called with parameters url
and text
.
@trombonehero if thatās what you need, that is possible today: Just create a shortcode.
A custom renderer could be useful for stuff that is not natural to solve with a sc.
One could imagine Hugo adding a config parameter saying:
- addBlankTargetToExtternalLinksInMarkdown
And do a check for urls not starting with single ā/ā.
See
This would be a global or per page setting, but better than nothing.
Pull requests welcome. Should be pretty straight forward, just look at the previous similar additions. Just ask.
The above issue is added to the latest source.
mmm, and of course, we need a non-global way to do this - using the source level linking - oh joys - which is only triggered for markdown style links.
only way to do it one off is inline HTML or a Shortcode. That is the defined way to do it in Markdown.
Iām going to port the GitHub linking PR to use mmark (as well as blackfriday) - as https://github.com/fletcher/MultiMarkdown/wiki/MultiMarkdown-Syntax-Guide#anchor-and-image-attributes gives me hope.
A slightly non-global way to do it is to set this Blackfriday option on a per-page basis ā¦ But I suspect this isnāt non-global enough.
@bep and @SvenDowideit, am I missing something? Iāve set the following in my config.toml
and it works like a charm:
[blackfriday]
plainIDAnchors = true
hrefTargetBlank = true
I have some handy javascript to that controls for things like mailto
and also works for hrefās ending in .pdf, excel, etc. Let me know if I can help. Cheers.
Oh yeah, and some JS for extra formatting flexibility with blockquotes. I hate using inline HTML in markdown if I can help it, since I think of markdown as an abstraction of all markup languages and not just HTML.
He wants to set it on a per-link basis. Currently you can set the target=_blank on site or per page.
Ah, terribly sorry. Figured I was missing something. Iām curious about this use case @SvenDowideit. Why would you need such granular control on a per-anchor basis? My assumption would just be for anchors to external sites and non-HTML documents (eg, .docx, .pdf, etc).