Permit adding attributes to all Markdown elements

[phyllisstein]

I'd like to suggest that Pandoc allow attributes to be attached to any Markdown element, not just code blocks. So for example, if it encountered this:

#{.main} Header

it would generate this:

<h1 class="main" id="header">Header</h1>

rather than this:

<h1 id="main-header">{.main} Header</h1>

Ditto for, say:

Header
----{.main}

...which is probably even legible enough to fit with Markdown's philosophical aversion to looking, well, marked-up.

[jamiefolson]

FYI conversations on this topic date back 5 years:

• discussing maruku's attributes
  • discussing implementation issues without expanding the syntax
  • this long but well-thought-out request for new syntax

I for one think it's surprising that nothing seems to have been done to facilitate this. I understand the desire not to pollute the syntax, but it seems like people are taking extraordinary measures to work around this limitation.

[jgm]

Would you count 1.11's allowing attributes to be added to headers
as progress?

[phyllisstein]

John,
I thought that was a terrific step, along with the inline_code_attributes extension. I'm looking forward to when classes and key/value pairs are implemented for headers, since the particular use case I had in mind involved setting an identifier and an onClick event.

Thanks so much for all your work on Pandoc; it's really a thing of beauty.

[jgm]

+++ Daniel Shannon [Mar 15 13 18:04 ]:

John,
I thought that was a terrific step, along with the
inline_code_attributes extension. I'm looking forward to when classes
and key/value pairs are implemented for headers, since the particular
use case I had in mind involved setting an identifier and an onClick
event.

They are already implemented in 1.11!

% pandoc
# Hi {#foo .bar .baz key=val}
^D
<h1 id="foo" class="bar baz" key="val">Hi</h1>

[jamiefolson]

I think attributes for headers are a great and wonderful thing. I also think that there are totally valid reasons for wanting to add attributes to arbitrary elements. For example, in the reports package for R, the author, possibly intimidated by haskell, resorted to a series of fragile regular expressions to try add the necessary classes and attributes to html output.

Certainly, the "fragment" class for reveal.js could and probably should be set by a new output format for pandoc, however, it's a lot harder to come up with a solution for the transition options. Both Beamer and reveal.js allow the user to configure how and when transitions occur (I don't know about all the other js templates).

Custom attributes would make it simple for reveal.js and even for beamer, the necessary script would not be complicated. Conceptually, such concepts as how and when to reveal an element feel like options rather than some new syntactic element. Alternative solutions would seem to require awkward detection and parsing of (to pandoc) literal string elements.

[luc-j-bourhis]

Imho tables are in dire need of that new syntax for attributes. It is not rare to need different tables to be displayed with different styles.

[thriveth]

And there are different LaTeX figure-environments. Allowing to set custom attributes to an image tag would mean one could more easily distinguish different kinds of figure. Other writers could simply ignore it.

[jgm]

@jamiefolson: pandoc now includes a uniform syntax for transitions, which gets output as \pause in beamer and using fragment divs in revealjs. Of course, you can also just use a <div class="fragment"> in the markdown source, but this won't be portable if you decide to switch to beamer.

@luc-j-bourhis, @thriveth: You can wrap a table or figure with a div that has attributes. Are there reasons the attributes have to be on the table or image itself?

[thriveth]

@jgm I wasn't aware of that, but looking at #1242 I can see it is possible, but also witht he caveats that @blaenk mentions there.
I understand that it would be very work heavy and difficult to implement without ambiguities and messy syntax, so I second @blaenk's suggestion to implement an attribute field to the image element (because I find I almost always need to add some kind of metadata/attribute to it) and leave the rest to div/span solutions.

[mb21]

With image attributes underway, I could take a look at adding attributes to a few more elements if this is desired:

• Link Syntax for classes in link definitions #170
• Table New Feature: internal links to tables and figures and headers #813
• BlockQuote (see example in uniform attribute lists #1242)

While the HTML writers would pass through all attributes, the others would just support the id and classes where appropriate. So beyond referencing tables and blockquotes, it would primarily enable simpler filters.

The exact markdown syntax for tables and blockquotes isn't exactly obvious, but I tend to favour the variant where the attributes have to be on their own line, trailing the actual table or blockquote (see the commonmark discussion and proposal).

[thriveth]

This is really great news!
Probably means I will soon be able to write journal article fully in
Pandoc Markdown without or almost without manual editing in LaTeX.

On 12/30/2014 01:42 PM, mb21 wrote:

With image attributes underway
#1806, I could take a look at
adding attributes to a few more elements if this is desired:

• |Link| Syntax for classes in link definitions #170 Syntax for classes in link definitions #170
• |Table| New Feature: internal links to tables and figures and headers #813 New Feature: internal links to tables and figures and headers #813
• |BlockQuote| (see example in uniform attribute lists #1242
  uniform attribute lists #1242)

While the HTML writers would pass through all attributes, the others
would just support the |id| and |classes| where appropriate. So beyond
referencing tables and blockquotes, it would primarily enable simpler
filters.

The exact markdown syntax for tables and blockquotes isn't exactly
obvious, but I tend to favour the variant where the attributes have to
be on their own line, trailing the actual table or blockquote (see the
commonmark discussion
http://talk.commonmark.org/t/consistent-attribute-syntax/272/ and
proposal https://mb21.github.io/stmd/spec.html#extensions).

—
Reply to this email directly or view it on GitHub
#684 (comment).