I have a render hook for images that applies a lightbox effect by nesting the img inside of an a.
When the writer now tries to nest an image inside of a link in Markdown like [](http://example.com) this results in invalid HTML markup like
So my question is: Can I detect in the image render hook if it currently is called nested, so to avoid applying the lightbox effect? Something like .Parent or so? I’ve checked the docs for render hooks but haven’t found anything.
There is no easy way to check this. And I suspect, there isn’t any way at all for Hugo to detect an image inside of a link, but I’m not sure.
My take on this would be to strongly discourage the use of nested images inside of links in Markdown. The resulting HTML is not only invalid in case of a render-image hook like yours, but always problematic. A Markdown link leads to an inline anchor tag <a> which gets the style display: inline by default. The enclosed image element also gets rendered to a tag (<img>) that is inline by default.
But what we really want to achieve with a link around an image element in HTML is usually a block element (or inline-block) with a defined height. And this is not what CommonMark can give us. It’s better to work with hooks that are able to apply a link like yours, so we can style the tags as blocks as we need them.
But what we really want to achieve with a link around an image element in HTML is usually a block element (or inline-block) with a defined height. And this is not what CommonMark can give us.
The discussion about block vs. inline is irrelevant. We should not assume the writers intention but solely rely on the provided markup/markdown.
Additionally Markdown will make an image block level by nesting it in a p if written on its own line. See CommonMark Spec
Yes, but with an isolated image inside a link we still get something like <p><a><img></a></p>. The paragraph block doesn’t solve the problem.
And the link around the image may not cover the whole area of the image because it’s inline. And every link around an image should cover the image, I would presume.
To make it clear: I don’t care about the behavior such a construct will generate. I also don’t care what the writer might have assumed.
My problem is, that my code results in invalid HTML.
Now someone could say: who cares, the browser will compensate for this. But as a theme author I care about HTML validity and don’t want to introduce funny CSS selectors to target the DOM that was rewritten by the browser.
Last resort is to throw some JS on it - but I would rather try to avoid this.
A render hook for a markdown heading should return a heading (example: <h1>foo</h1>).
A render hook for a markdown link should return a link (example: <a href="foo">foo</a>).
A render hook for a markdown image should return an image (example: <img src="foo">)
We made an exception to the third assertion with 63126c63, which allows you to render a syntactically correct figure element when an image appears by itself (stand-alone) in markdown.
The exception was made to accommodate a frequent use case.
Other than this exception, I stand by my assertion:
A render hook for a markdown image should return an image