By default, Goldmark does not render raw HTMLs and potentially dangerous links. If you have lots of inline HTML and/or JavaScript, you may need to turn this on.
I personally haven’t found raw HTML “unsafe”1 because I source-control my Hugo site source and I know what is getting committed.
On the contrary, raw HTML is necessary to allow interleaving the Markdown text with HTML features like <details> and <summary> tag, <mark> to highlight some stuff, <div> wrappers to wrap something in a class for CSS, <div> and <span> for captioning code blocks, etc.
This recent blog post probably uses all of these raw HTML – see the Markdown source of the post.
You can of course hide these HTML tags in shortcodes, but I refrain from using them as I want the Markdown to be more universal, i.e. use as much of CommonMark syntax as possible. CommonMark by default supports raw HTML.
I find the ability to use raw HTML indispensable. So I was curious how the people here were setting that “unsafe” option.
unsafe = true (allow raw HTML in Markdown content)
unsafe = false (default as of 2022/03/08 – do not allow raw HTML in Markdown content)
I am not aware of this option
0voters
1 Users serious about the security of their website should consider using strict CSP or Content Security Policy headers.
I accidentally clicked unsafe=true but meant to click false. You are using too much formatting in your posts I recently added your blog to my reading list and there too are so many different formattings that I think my brain might be on the completely opposite side of your brain :D, sorry for that.
Anyway…
unsafe = false - because: Unsafe for me means I was not able to write proper markdown. It is one thing to do that on your own website, but if you (and I know you do) create code for customers you should always assume that they WILL BREAK IT… as in they will find that one user case where everything explodes. Keeping the end-user within restrictive borders is some form of kindergarten management, yes, but you keep the issues low. If there is a need to add unsafe=true to a project, then there is a reason to add a shortcode that solves this issue.
I have this thing where I hate Hugo’s restrictive security policies (and with that basically Golangs restrictive security policies, because they are the ones doing that) but also think that they have a reason to be implemented. So, well, they are right.
Long story short: unsafe = true is a sign that something is done wrong in a Hugo project. IMHO. The H means humble.
I like that criticism! Please give me some suggestions, may be by directly messaging in this forum if you wish (as I don’t want to detract from the topic of this post.)
short: unsafe = true is a sign that something is done wrong in a Hugo project.
I use Org mode for formatting my posts. Org mode supports a lot more formatting than Markdown does. So I simply have the Org markup export as raw HTML for the stuff unsupported in Markdown (like the details/summary or mark tags).
I see unsafe = true as unshackling oneself from the bounds of Markdown
yeah, that is the two-sided-brain-thingy I was talking about. It’s either “Hugo is a static site generator that generates websites from Markdown” or “Hugo creates my site” So I guess if you are on the Markdown-is-shackles-side then the unsafe option is great. I don’t have any experience with org-mode. For me having shackles will keep things in line. It’s good, but it’s bad. I get it
I recently went through the painstaking task of removing HTML from my posts and then set unsafe to false. I find shortcodes easier to use for the limited cases I need HTML in markdown. The only thing I had to sacrifice is <cite></cite> which I wish Markdown would support.
I use prism.js for highlighting code samples. Therefore I use unsafe = true, because with unsafe = false I had problems with the display of the code samples.
In my case, it’s a sign that I have thousands of blog posts dating back to 2002 that were converted from MovableType, and it was hard enough to convert from Blackfriday to Goldmark without banging my head against the limitations of CommonMark. As it is, I spent quite a while coming up with a workaround for the misnamed “typographer” extension.
@jgreely Most of the known issues with Goldmark’s typographer extension were addressed with yuin/goldmark/pull/280 which is included with Hugo v0.93.3.
Thanks. Since the primary GM developer wasn’t interested, I figured it would never get done. Sadly, it took so long that I gave up and wrote a script to convert 4,000+ old blog entries using the reference implementation of CommonMark, so that I wasn’t stuck using the deprecated Blackfriday rendering.
I recently added your blog to my reading list and there too are so many different formattings that I think my brain might be on the completely opposite side of your brain :D, sorry for that.