#[fluffy]There are markdown extensions that let you add arbitrary HTML attributes to things, although they vary a lot based on processor.
#[KevinMarks]It's in the specs, some silos censor html
#[fluffy]But once you get to the point of adding attributes to Markdown you’re giving up a lot of the safety and simplicity of Markdown and almost reinventing HTML the long way around.
#[fluffy]Not to mention all of the “fun” of dealing with 29380280 different incompatible Markdown extension syntaxes.
marksuth1, [schmarty]1, [tw2113_Slack_]1, [snarfed], IWSlackGateway3 and [fluffy] joined the channel
#[fluffy]For the specific case of markdown and microformats it’s generally better to put that on your rendering template and provide a mechanism for sidecar metadata, which most SSG-style publishing systems allow.
#capjamesg[d]I do actually put HTML w/ microformats in .md files on my blog. But that's only because I read front-matter values for them and Jekyll supports this behavior.
#capjamesg[d]I wouldn't write HTML in an .md file that I planned to share unless I knew that the consumer would be able to interpret it (i.e. in the case of Jekyll where I can specify front matter that is then substituted into the HTML). HTML is always first for markup.
#capjamesg[d]Admittedly, I haven't looked into Publ that much. I shall have to do so!
#[fluffy]I only use .md for content files, and I only use HTML directly if there’s something .md can’t do cleanly, like complex table structure or iframe embeds or whatever.
#[fluffy]But anyway this is like… riding the knife’s edge of #microformats chat
#capjamesg[d]Yep. I think we're getting off topic. We can continue in an #indieweb chat.
#[fluffy]Basic point being that yeah there’s no reason to support microformats in Markdown itself, it should be handled by your rendering templates + frontmatter/metadata mechanism, or by embedding raw HTML for particularly weird cases.
#capjamesg[d]And most parsers are written with HTML content in mind, right?