blackfriday
blackfriday copied to clipboard
russross
Customising the output HTML / adding classes to tags
I'm using Hugo which uses blackfriday to create HTML from Markdown. In my HTML I need my generated tables tags to have class="table" added to the table tag. (This is so the generated table is correctly formatted by bootstrap 3).
If I controlled the Go program using blackfriday I would create my own blackfriday.Renderer, subclassing blackfriday.HTML, and tweak the outputted HTML to be how I needed it. However I don't have that luxury with Hugo. So instead it would be good if there was some kind of flexible/extensible configuration that allowed me to customise the HTML. I don't exactly know what it would look like, but perhaps some map of tag names, to additional attributes/classes/something.
Yes, please!!
![Picture][/picture.jpg]{: class=img-responsive } or ![Picture][/picture.jpg]{: .img-responsive } http://maruku.rubyforge.org/proposal.html#attribute_lists http://pythonhosted.org/Markdown/extensions/attr_list.html
Agreed. I just made a similar request in the Hugo repo: spf13/hugo#1585
I understand the motivation for this request, and I think it belongs more on Hugo side. Blackfriday already supports somewhat flexible means of customizing or tweaking the rendering, as you mentioned:
my own blackfriday.Renderer, subclassing blackfriday.HTML, and tweak the outputted HTML
It's something we're trying to improve more in a future v2 of blackfriday (see #218 and #120).
However, it seems the best way to resolve this need is for Hugo to provide better support to let you customize its Markdown rendering. Since blackfriday has some flexibility already, Hugo just needs to take advantage of that and come up with some means for users to tweak the output.
Of course, this request is good to take note of and it'll influence v2 design, so thanks for reporting.
I can totally understand that point, but I'd argue that this functionality would be super-useful for any consumer of Blackfriday. Attribute lists are becoming a standard (supported by both Kramdown and Maruku), and are generally useful for anyone producing HTML. Requiring that each client add this themselves feels like a lot of waste.
Here are some examples:
A simple paragraph with an ID attribute.
{: #para-one}
> A blockquote with a title
{:title="The blockquote title"}
{: #myid}
This *is*{:.underline} some `code`{:#id}{:.class}.
A [link](test.html){:rel='something'} and some **tools**{:.tools}.
I'm also looking forward to seeing class and ID support — as illustrated by @tsaleh above — land in Blackfriday.
I've used this extensively in Kramdown and it's one of the few things I'm missing in Blackfriday right from the start...
:+1:
Another use case would be for multilingual content.
> Je pense donc je suis.
{:lang="fr"}
Maruku already does this behavior an also has an proposal. I also would like this feature, because of caddy. :)
Did anything every come of this, it definitely feels like something that would benefit all blackfriday implementations rather than specifically hugo?
I personally do not want to spend time on anything altering source document interpretation until we are Common Mark compliant. After that it will be easier to judge the implications.
On the gut level, though, this functionality looks like a huge step back to HTML. Too much markup, very unmarkdownlike in spirit.
But probably worth trying to achieve via AST post-processing in v2.
But probably worth trying to achieve via AST post-processing in v2.
I assume that, for this to be possible, there must be some kind of processing tokens that gets ignored by default? Is that included in the v2 parser spec?
I assume that, for this to be possible, there must be some kind of processing tokens that gets ignored by default? Is that included in the v2 parser spec?
No, it's not included (and there's no such spec, unfortunately :-)). I didn't mean to suggest it would be possible to implement exactly what people are asking here in v2. No, it would still mean altering interpretation of the source document, and I see that as a flaw, unless all implications of such change are considered.
What I did mean to suggest was a workaround: for somebody storing those attributes as metadata outside of the document, or somehow else having insights into the document's structure, the metadata can be merged into AST during post-processing.
What I did mean to suggest was a workaround: for somebody storing those attributes as metadata outside of the document
That may solve the adding class="table" to all tables (which I guess is also possible today), but not the class="warning" ... or error or whatever. You may argue that this simple example is "too markupish", but it is a very common requirement. In Hugo we have created shortcodes as a way to include HTML and template logic in markdown files, but this is little bit overkill for simple processing instructions.
As I understand it, Blackfriday v2 has a strict split between Parse and Render, which I guess also encourages people to write their own renderers. CSS classes may be processing instruction set for HTML, other rendering formats will have "something else". Having a "general token" that the renderers can ignore if they want would be great.
re: does this belong in Hugo or BlackFriday. What about pushing this up further to CommonMark? It is currently the #3 most discussed feature request.
This would be an amazing feature!
I quite like using it with markdown-it in Node and kramdown in Ruby/Jekyll.
It is very helpful to label content and to display it differently—I use to enable writers to put the content in the sidebar while they still write in the continuous flow of the Markdown file.
I have recently used that for accessibility reasons, in order to write down a long description with ARIA attributes:
{: aria-describedby="timeline-text" }
1. Phase One
- 2011 : ...
- 2012 : ...
1. Phase Two
- 2013 : ...
- 2013 : ...
- 2015 : ..
{: id="timeline-text" }
Hi, I hope it's not obnoxious to add a comment here asking whether there's any prospect of an implementation going forward. I really miss this feature from markdown-it and some other tools. https://github.com/gohugoio/hugo/issues/5124 discusses this issue a bit but seems to have been closed without resolution. Would love to hear what's going on here...
