Render attribute tags with double quotes instead of single quotes as default

[leifriksheim]

I'm writing a custom plugin for a markdown parser. I'm using Himalaya to make an AST, append some tags and return the text again to the parser. The problem is that the parser (showdownjs) won't render the html correctly because it want's to receive <div class="my-class"> but the stringify function returns <div class='my-class'>

It could be intentional, but I think it would make sense to render attribute tags with double quotes instead of single quotes as default. Or maybe make it available in options at least?

himalaya/src/stringify.js

Line 10 in f0b8700

const quote = quoteEscape ? '"' : '\''

[andrejewski]

Thanks for the issue, @leifriksheim. HTML allows both single and double quotes so I would open an issue with showdown (though given its longevity I would expect an issue to already exist).

In the meantime, I will consider adding a new option. Right now I see 4 strategies:

• Single default, then double
• Double default, then single
• Single and encode entities
• Double and encode entities

I am not seeing a straight forward solution to the encoding bit. I would like to make us more resilient in the case that both single and double quotes are used in the attribute value if it does not complicate things too much. If it turns out to be hard, it may be worth making a himalaya-* package to help in these cases.

In the mean-meantime feel free to copy/paste the stringify function into a util and bend it to your will.

[leifriksheim]

Thank you for a quick answer! I'll copy/paste for now. Love the package btw, exactly what I was looking for!

[andrejewski]

After giving this some thought I think the best approach is to make a new package like himalaya-stringify which exports a stringify that takes more options. In particular I think to solve this problem a serializeAttributeValue: (string | null, attributeName: string) => string | null option.

The reason a brand new package is preferable:

• Room for experimentation in its own realm
• Not bloating Himalaya with options needed by only a fraction of people
• Freedom to get into the weeds and maybe add some dependencies. Himalaya has no non-dev dependencies on purpose because they are a huge management pain
• Freedom not to be blocked by me
• We can always integrate the best parts of the new package into a minor or major release once things are fleshed out

@leifriksheim If you want to take over that endeavor I'm all for it. We can talk about potential APIs to expose and what not for the new package if you want. If that's too much work, someone else may pick it up or I'll keep it in the back of my mind for a future release as a potential enhancement.