Custom Markdown Attributes not (completely) working for Paragraphs

Hello all!

I’m using WindiCSS in my Hugo project. The primary reason for choosing it was the Attributify mode. So I could add a margin to top like: <div w:m = "t-5">. I migrated my entire project from Tailwind yesterday and then I realised I missed one thing. I totally forgot about my Markdown content. At first, it appeared not to be too much of an issue, but I soon ran into the following problem:

## Heading
{w:snap = "mt-5" w:text = "2xl"}

{w:m = "t-2.5"}

In this, the heading is getting the attributes I’m trying to set. So it is rendered correctly. However, the <p> tag is rendered without the attribute. I checked further and the following works:


{class = "mt-2.5"}

{title = "some text"}

Basically, I’m able to set class with .class, class = "" and even the title attribute is working. However, the custom attribute doesn’t work.

Even the following doesn’t work:

{class = "mt-2.5" w:m = "t-2.5"}

In this case, only the class is added, the custom attribute is still ignored.

So is there a limitation which allows only class, ID and title to be set (I could only see those being used in examples all around)?


I have the following in my config.toml:

  block = true

And here’s a test repo:

Run npm i && npm run dev.

Hugo supports attributes attached to three markdown elements:

  1. Code fences
  2. Headings
  3. Blocks

As far as I can tell, Hugo handles the first two natively, but we farm #3 out to Goldmark.

Goldmark has an “allowed list” of attributes: a global list (attributes allowed on any element) and a list specific to each element. Attributes such as bg and font are not valid HTML attributes on any element, so they are discarded. The same is true with any namespaced attribute, regardless of whether or not the attribute is allowed for the element with which it is associated.

So we could:

  1. Ask the Goldmark project to support invalid HTML attributes, with and without namespaces
  2. Handle block attributes internally, as it looks like we do with code fences and headings.

I could be wrong, but I don’t think #1 will ever happen.
I have no idea how difficult #2 would be, but I don’t think it would be quick or easy.

Thank you for that complete information.

Well, looks like the current option is to stick with class names or supply a global CSS style (like p+p{}) to the entire thing.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.