New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permit adding attributes to all Markdown elements #684

Open
phyllisstein opened this Issue Dec 6, 2012 · 81 comments

Comments

Projects
None yet
@phyllisstein

phyllisstein commented Dec 6, 2012

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

This comment has been minimized.

Show comment
Hide comment
@jamiefolson

jamiefolson Mar 16, 2013

Contributor

FYI conversations on this topic date back 5 years:

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.

Contributor

jamiefolson commented Mar 16, 2013

FYI conversations on this topic date back 5 years:

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

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Mar 16, 2013

Owner

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

Owner

jgm commented Mar 16, 2013

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

@phyllisstein

This comment has been minimized.

Show comment
Hide comment
@phyllisstein

phyllisstein Mar 16, 2013

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.

phyllisstein commented Mar 16, 2013

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

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Mar 16, 2013

Owner

+++ 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>
Owner

jgm commented Mar 16, 2013

+++ 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

This comment has been minimized.

Show comment
Hide comment
@jamiefolson

jamiefolson Mar 16, 2013

Contributor

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.

Contributor

jamiefolson commented Mar 16, 2013

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

This comment has been minimized.

Show comment
Hide comment
@luc-j-bourhis

luc-j-bourhis Mar 26, 2013

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.

luc-j-bourhis commented Mar 26, 2013

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

This comment has been minimized.

Show comment
Hide comment
@thriveth

thriveth Apr 9, 2014

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.

thriveth commented Apr 9, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Apr 13, 2014

Owner

@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?

Owner

jgm commented Apr 13, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@thriveth

thriveth Apr 14, 2014

@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.

thriveth commented Apr 14, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Dec 30, 2014

Collaborator

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

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).

Collaborator

mb21 commented Dec 30, 2014

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

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 comment has been minimized.

Show comment
Hide comment
@thriveth

thriveth Dec 30, 2014

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:

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).

thriveth commented Dec 30, 2014

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:

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).

@jamiefolson

This comment has been minimized.

Show comment
Hide comment
@jamiefolson

jamiefolson Dec 30, 2014

Contributor

This would be fantastic. Even if attributes are mostly only available in
the data model for filtering that enables a large number of currently
difficult use cases.

Jamie Olson

On Tue, Dec 30, 2014 at 8:59 AM, Thøger Rivera-Thorsen <
notifications@github.com> wrote:

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:

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).


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

Contributor

jamiefolson commented Dec 30, 2014

This would be fantastic. Even if attributes are mostly only available in
the data model for filtering that enables a large number of currently
difficult use cases.

Jamie Olson

On Tue, Dec 30, 2014 at 8:59 AM, Thøger Rivera-Thorsen <
notifications@github.com> wrote:

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:

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).


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

@stroobandt

This comment has been minimized.

Show comment
Hide comment
@stroobandt

stroobandt May 24, 2015

This issue is also listed as item 2 on this list. (Disclaimer: I have no relation to that web site.)

stroobandt commented May 24, 2015

This issue is also listed as item 2 on this list. (Disclaimer: I have no relation to that web site.)

@fmatheus

This comment has been minimized.

Show comment
Hide comment
@fmatheus

fmatheus Oct 14, 2015

Would be great if any header_attributes was supported in beamer output.
Looks like {.allowframebreaks} and .fragile by test made in 1.15.0.6.
But why not support arbitrary attributes? In particular c, noframenumbering and plain.

fmatheus commented Oct 14, 2015

Would be great if any header_attributes was supported in beamer output.
Looks like {.allowframebreaks} and .fragile by test made in 1.15.0.6.
But why not support arbitrary attributes? In particular c, noframenumbering and plain.

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Oct 14, 2015

Owner

+++ fmatheus [Oct 14 15 15:05 ]:

Would be great if any header_attributes was supported in beamer output.
Looks like {.allowframebreaks} and .fragile by test made in 1.15.0.6.
But why not support arbitrary attributes? In particular c,
noframenumbering and plain.

Sounds plausible to me. This just takes a small change in
the LaTeX writer.

Owner

jgm commented Oct 14, 2015

+++ fmatheus [Oct 14 15 15:05 ]:

Would be great if any header_attributes was supported in beamer output.
Looks like {.allowframebreaks} and .fragile by test made in 1.15.0.6.
But why not support arbitrary attributes? In particular c,
noframenumbering and plain.

Sounds plausible to me. This just takes a small change in
the LaTeX writer.

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Oct 15, 2015

Owner

+++ fmatheus [Oct 14 15 15:05 ]:

Would be great if any header_attributes was supported in beamer output.
Looks like {.allowframebreaks} and .fragile by test made in 1.15.0.6.
But why not support arbitrary attributes? In particular c,
noframenumbering and plain.

I've added support for all frame attributes in commit
504bf3f

Owner

jgm commented Oct 15, 2015

+++ fmatheus [Oct 14 15 15:05 ]:

Would be great if any header_attributes was supported in beamer output.
Looks like {.allowframebreaks} and .fragile by test made in 1.15.0.6.
But why not support arbitrary attributes? In particular c,
noframenumbering and plain.

I've added support for all frame attributes in commit
504bf3f

@stroobandt

This comment has been minimized.

Show comment
Hide comment
@stroobandt

stroobandt Oct 16, 2015

Sounds plausible to me. This just takes a small change in the LaTeX writer.

Attributes to all Markdown elements is not only useful to LaTeX and Beamer.
I personally can think of many use cases for it as XHTML classes.

stroobandt commented Oct 16, 2015

Sounds plausible to me. This just takes a small change in the LaTeX writer.

Attributes to all Markdown elements is not only useful to LaTeX and Beamer.
I personally can think of many use cases for it as XHTML classes.

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Oct 16, 2015

Owner

+++ Serge Y. Stroobandt [Oct 16 15 06:24 ]:

Sounds plausible to me. This just takes a small change in the LaTeX
writer.
Attributes to all Markdown elements is not only useful to LaTeX and
Beamer.
I personally can think of many use cases for it as XHTML classes.

Sure. I was responding to the (misplaced) previous comment which just
concerned Beamer attributes on headers, not to this general issue.

Owner

jgm commented Oct 16, 2015

+++ Serge Y. Stroobandt [Oct 16 15 06:24 ]:

Sounds plausible to me. This just takes a small change in the LaTeX
writer.
Attributes to all Markdown elements is not only useful to LaTeX and
Beamer.
I personally can think of many use cases for it as XHTML classes.

Sure. I was responding to the (misplaced) previous comment which just
concerned Beamer attributes on headers, not to this general issue.

@jmuheim

This comment has been minimized.

Show comment
Hide comment
@jmuheim

jmuheim Nov 25, 2015

@jgm:

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

How can an ID be applied to a link? The following doesn't work:

[Als DOCX downloaden](somewhere.html) {#download_as_docx}

jmuheim commented Nov 25, 2015

@jgm:

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

How can an ID be applied to a link? The following doesn't work:

[Als DOCX downloaden](somewhere.html) {#download_as_docx}
@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Nov 26, 2015

Owner

You need the very latest dev version of pandoc to apply an
ID to a link (compile from source). And you can't have a
space before the {.

+++ Joshua Muheim [Nov 25 15 14:38 ]:

[1]@jgm:
% pandoc

Hi {#foo .bar .baz key=val}

^D

Hi

How can an ID be applied to a link? The following doesn't work:
Als DOCX downloaden {#download_as_docx}


Reply to this email directly or [2]view it on GitHub.

References

  1. https://github.com/jgm
  2. #684 (comment)
Owner

jgm commented Nov 26, 2015

You need the very latest dev version of pandoc to apply an
ID to a link (compile from source). And you can't have a
space before the {.

+++ Joshua Muheim [Nov 25 15 14:38 ]:

[1]@jgm:
% pandoc

Hi {#foo .bar .baz key=val}

^D

Hi

How can an ID be applied to a link? The following doesn't work:
Als DOCX downloaden {#download_as_docx}


Reply to this email directly or [2]view it on GitHub.

References

  1. https://github.com/jgm
  2. #684 (comment)
@ousia

This comment has been minimized.

Show comment
Hide comment
@ousia

ousia Nov 28, 2015

Contributor

@jgm, will all elements have attributes in Markdown?

Contributor

ousia commented Nov 28, 2015

@jgm, will all elements have attributes in Markdown?

@jmuheim

This comment has been minimized.

Show comment
Hide comment
@jmuheim

jmuheim Jan 25, 2016

@jgm, which version is this? I have 1.15.2.1, which came with homebrew.

jmuheim commented Jan 25, 2016

@jgm, which version is this? I have 1.15.2.1, which came with homebrew.

@ousia

This comment has been minimized.

Show comment
Hide comment
@ousia

ousia Jan 25, 2016

Contributor

It comes in version 1.16.x. Latest released version is 1.16.0.2.

Contributor

ousia commented Jan 25, 2016

It comes in version 1.16.x. Latest released version is 1.16.0.2.

@elotroalex

This comment has been minimized.

Show comment
Hide comment
@elotroalex

elotroalex Feb 28, 2016

Any updates on this? We're trying to create a workflow that will produce a web version and a print version from the same markdown file. We're using Jekyll for web deployment. Jekyll usually plays nice with kramdown, but @mfenner has been working on a gem called jekyll-pandoc. We've been knocking our heads silly trying to decide how to handle poetry. (We're lit folks). At issue right now is the inability to handle classes at the line level so we can make the right CSS to wrap our lines nicely, etc. Kramdown handles this exceptionally well, but then we'll be giving up our workflow for pandoc | *TeX which depends on pandoc-markdown. If we can get pandoc-markdown to work well with Jekyll + poetry, we will have devised an excellent solution for a large community of editors and scholars who can now produce nice PDF's and nice websites out of the same files. We're trying at all costs to avoid to have to write filters, or divide the editing workflow into two parts. Can we get attributes at the unnumbered list line and block level, and its corollary the blockquoted unnumbered list? Or is this out with the new implementation and I missed something?

elotroalex commented Feb 28, 2016

Any updates on this? We're trying to create a workflow that will produce a web version and a print version from the same markdown file. We're using Jekyll for web deployment. Jekyll usually plays nice with kramdown, but @mfenner has been working on a gem called jekyll-pandoc. We've been knocking our heads silly trying to decide how to handle poetry. (We're lit folks). At issue right now is the inability to handle classes at the line level so we can make the right CSS to wrap our lines nicely, etc. Kramdown handles this exceptionally well, but then we'll be giving up our workflow for pandoc | *TeX which depends on pandoc-markdown. If we can get pandoc-markdown to work well with Jekyll + poetry, we will have devised an excellent solution for a large community of editors and scholars who can now produce nice PDF's and nice websites out of the same files. We're trying at all costs to avoid to have to write filters, or divide the editing workflow into two parts. Can we get attributes at the unnumbered list line and block level, and its corollary the blockquoted unnumbered list? Or is this out with the new implementation and I missed something?

@ousia

This comment has been minimized.

Show comment
Hide comment
@ousia

ousia Feb 28, 2016

Contributor

I think the basic issue is the following:

If Markdown is based on HTML, Markdown should have three basic attributes in all elements.

And sorry, if LaTeX cannot handle this, we should find another way of dealing with XML when using LaTeX.

Contributor

ousia commented Feb 28, 2016

I think the basic issue is the following:

If Markdown is based on HTML, Markdown should have three basic attributes in all elements.

And sorry, if LaTeX cannot handle this, we should find another way of dealing with XML when using LaTeX.

@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Feb 28, 2016

Collaborator

We have now Attr (i.e. attribute support) also on Image and Link elements, as can be seen on the pandoc-types Definition.hs. To add it to further elements, we'll have to change the types and then change all the writers, which takes a lot of work and is a breaking change for filters etc. Still, I hope we'll be able to add it to more elements in the future... contributions welcome :)

Collaborator

mb21 commented Feb 28, 2016

We have now Attr (i.e. attribute support) also on Image and Link elements, as can be seen on the pandoc-types Definition.hs. To add it to further elements, we'll have to change the types and then change all the writers, which takes a lot of work and is a breaking change for filters etc. Still, I hope we'll be able to add it to more elements in the future... contributions welcome :)

@elotroalex

This comment has been minimized.

Show comment
Hide comment
@elotroalex

elotroalex Feb 28, 2016

Thanks, @mb21. Good to hear you're still moving on this. Contributions might be forthcoming once I find a friend who can do Haskell (or time to learn myself). I see you have this generic

| Span Attr [Inline] -- ^ Generic inline container with attributes

I can't parse haskell very well, so I apologize if this sounds dumb. What is this generic inline container?

elotroalex commented Feb 28, 2016

Thanks, @mb21. Good to hear you're still moving on this. Contributions might be forthcoming once I find a friend who can do Haskell (or time to learn myself). I see you have this generic

| Span Attr [Inline] -- ^ Generic inline container with attributes

I can't parse haskell very well, so I apologize if this sounds dumb. What is this generic inline container?

@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Feb 28, 2016

Collaborator

It's literally the native pandoc span element (there's also a div element). Unfortunately there's no markdown syntax yet (but most probably it'll be [my text]{.myClass})—meanwhile you can write inline HTML:

echo 'some _italic_ markdown with <span class="myClass">my text</span>' | pandoc -t native

The Attr means it holds attribute and the [Inline] means a list of Inline elements. see http://learnyouahaskell.com/making-our-own-types-and-typeclasses#algebraic-data-types for an introduction into haskell data types (the whole pandoc internal document AST is such a data type).

Collaborator

mb21 commented Feb 28, 2016

It's literally the native pandoc span element (there's also a div element). Unfortunately there's no markdown syntax yet (but most probably it'll be [my text]{.myClass})—meanwhile you can write inline HTML:

echo 'some _italic_ markdown with <span class="myClass">my text</span>' | pandoc -t native

The Attr means it holds attribute and the [Inline] means a list of Inline elements. see http://learnyouahaskell.com/making-our-own-types-and-typeclasses#algebraic-data-types for an introduction into haskell data types (the whole pandoc internal document AST is such a data type).

@elotroalex

This comment has been minimized.

Show comment
Hide comment
@elotroalex

elotroalex Feb 28, 2016

Thanks, @mb21. This is very useful. We've decided to use some HTML tags until further notice to deal with poetry. Here's looking forward to having both this new [my text]{.myClass} syntax and the coveted attribute class for any element.

Thanks for the link to this tutorial also. It seems very complete and approachable. I got the gist of the data types right away. Perhaps it will be me or someone in my team who implements, after all.

elotroalex commented Feb 28, 2016

Thanks, @mb21. This is very useful. We've decided to use some HTML tags until further notice to deal with poetry. Here's looking forward to having both this new [my text]{.myClass} syntax and the coveted attribute class for any element.

Thanks for the link to this tutorial also. It seems very complete and approachable. I got the gist of the data types right away. Perhaps it will be me or someone in my team who implements, after all.

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Feb 28, 2016

Owner

You know about line blocks, right?

http://pandoc.org/README.html#line-blocks

This will give you control over line breaking and initial
indentation, without sacrificing source readability.

If you want more control, you can wrap a line block in a div
with a class, and you can wrap individual lines in a span.

Owner

jgm commented Feb 28, 2016

You know about line blocks, right?

http://pandoc.org/README.html#line-blocks

This will give you control over line breaking and initial
indentation, without sacrificing source readability.

If you want more control, you can wrap a line block in a div
with a class, and you can wrap individual lines in a span.

@elotroalex

This comment has been minimized.

Show comment
Hide comment
@elotroalex

elotroalex Feb 28, 2016

Hi, @jgm. Sorry I missed you the last time you came to Columbia. @denten tells me it went really well.

So, yes, we know about the line blocks. We're juggling between those and unnumbered lists. Thanks for incorporating that syntax, btw. It is definitely useful. We were butting heads against the line wrap issue, that we could easily wrangle with the {.class} syntax, and also right now we're having some issues with ConTeXt playing nice with the line blocks. I feel we're very close to solving the ConTeXt problem, so that would only leave the line wrap problem for us. And of course, we're very aware that we can solve almost everything right now using the <div> and <span> that you provide. Our ultimate goal though is to reduce the syntax as much as possible for our editors and scholars, and achieve Gruber's dream of keeping all text relatively readable in the markdown itself.

Thanks again, for jumping in.

elotroalex commented Feb 28, 2016

Hi, @jgm. Sorry I missed you the last time you came to Columbia. @denten tells me it went really well.

So, yes, we know about the line blocks. We're juggling between those and unnumbered lists. Thanks for incorporating that syntax, btw. It is definitely useful. We were butting heads against the line wrap issue, that we could easily wrangle with the {.class} syntax, and also right now we're having some issues with ConTeXt playing nice with the line blocks. I feel we're very close to solving the ConTeXt problem, so that would only leave the line wrap problem for us. And of course, we're very aware that we can solve almost everything right now using the <div> and <span> that you provide. Our ultimate goal though is to reduce the syntax as much as possible for our editors and scholars, and achieve Gruber's dream of keeping all text relatively readable in the markdown itself.

Thanks again, for jumping in.

@elotroalex

This comment has been minimized.

Show comment
Hide comment
@elotroalex

elotroalex Feb 28, 2016

Hm. Maybe if I show you how I was solving this problem using kramdown/jekyll for my Ed project so the thread can get a clearer sense of the need:

- O Captain! my Captain! our fearful trip is done;
- The ship has weather’d every rack, the prize we sought is won,
- The port is near, the bells I hear, the people all exulting,
- While follow eyes the steady keel, the vessel grim and daring; 
- {:.indent-3}But O heart! heart! heart!
- {:.indent-4}O the bleeding drops of red,
- {:.indent-5}Where on the deck my Captain lies,
- {:.indent-6}Fallen cold and dead.

After it's processed by the kramdown engine this renders beautifully, and the lines wrap on smaller screens.

elotroalex commented Feb 28, 2016

Hm. Maybe if I show you how I was solving this problem using kramdown/jekyll for my Ed project so the thread can get a clearer sense of the need:

- O Captain! my Captain! our fearful trip is done;
- The ship has weather’d every rack, the prize we sought is won,
- The port is near, the bells I hear, the people all exulting,
- While follow eyes the steady keel, the vessel grim and daring; 
- {:.indent-3}But O heart! heart! heart!
- {:.indent-4}O the bleeding drops of red,
- {:.indent-5}Where on the deck my Captain lies,
- {:.indent-6}Fallen cold and dead.

After it's processed by the kramdown engine this renders beautifully, and the lines wrap on smaller screens.

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Feb 28, 2016

Owner

What an ugly way to write a poem! Here's how you'd do it in pandoc's Markdown:

| O Captain! my Captain! our fearful trip is done;
| The ship has weather’d every rack, the prize we sought is won,
| The port is near, the bells I hear, the people all exulting,
| While follow eyes the steady keel, the vessel grim and daring; 
|       But O heart! heart! heart!
|          O the bleeding drops of red,
|            Where on the deck my Captain lies,
|              Fallen cold and dead.
Owner

jgm commented Feb 28, 2016

What an ugly way to write a poem! Here's how you'd do it in pandoc's Markdown:

| O Captain! my Captain! our fearful trip is done;
| The ship has weather’d every rack, the prize we sought is won,
| The port is near, the bells I hear, the people all exulting,
| While follow eyes the steady keel, the vessel grim and daring; 
|       But O heart! heart! heart!
|          O the bleeding drops of red,
|            Where on the deck my Captain lies,
|              Fallen cold and dead.
@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Feb 28, 2016

Owner

I see what you mean about wrapping; on small screens you want the lines to wrap with some indentation, and the above doesn't do that. Well, since you're comfortable abusing unordered lists, you could always use nested lists to get the indentation you need:

- O Captain! my Captain! our fearful trip is done;
- The ship has weather’d every rack, the prize we sought is won,
- The port is near, the bells I hear, the people all exulting,
- While follow eyes the steady keel, the vessel grim and daring; 
    - But O heart! heart! heart!
        - O the bleeding drops of red,
            - Where on the deck my Captain lies,
                - Fallen cold and dead.

With appropriate CSS, this could behave just like what you have.

Markdown is meant to be readable as it stands. Explict attributes should be used only when necessary. I think that both of the methods I've suggested give you something that's much more readable in the source. The first method has the advantage of working well in all output formats, without special CSS (though you don't get as nice behavior on small screens).

If you really want to use ugly stuff, though, you could do something like:

- <span class="indent-3">But O heart! heart! heart!</span>

and so on. A little more to write, but it will give you Markdown that works everywhere.

Owner

jgm commented Feb 28, 2016

I see what you mean about wrapping; on small screens you want the lines to wrap with some indentation, and the above doesn't do that. Well, since you're comfortable abusing unordered lists, you could always use nested lists to get the indentation you need:

- O Captain! my Captain! our fearful trip is done;
- The ship has weather’d every rack, the prize we sought is won,
- The port is near, the bells I hear, the people all exulting,
- While follow eyes the steady keel, the vessel grim and daring; 
    - But O heart! heart! heart!
        - O the bleeding drops of red,
            - Where on the deck my Captain lies,
                - Fallen cold and dead.

With appropriate CSS, this could behave just like what you have.

Markdown is meant to be readable as it stands. Explict attributes should be used only when necessary. I think that both of the methods I've suggested give you something that's much more readable in the source. The first method has the advantage of working well in all output formats, without special CSS (though you don't get as nice behavior on small screens).

If you really want to use ugly stuff, though, you could do something like:

- <span class="indent-3">But O heart! heart! heart!</span>

and so on. A little more to write, but it will give you Markdown that works everywhere.

@elotroalex

This comment has been minimized.

Show comment
Hide comment
@elotroalex

elotroalex Feb 28, 2016

Ah, yes I know. It is a fantastic way of writing it in pandoc's Markdown. The only problem is having the lines wrap properly on small screens or big fonts, given that this produces a <p> tag for the stanza, with line ends being <br/>. We're working out the possibilities. Our ideal situation would be to be able to wrap these lines in line-blocks with hanging indentation using the syntax as-is, or the plan B, not as elegant, but elegant enough, {.foo} solution that you offer, as opposed to kramdown's. (which is at least better than kramdown's:

- O Captain! my Captain! our fearful trip is done;
- The ship has weather’d every rack, the prize we sought is won,
- The port is near, the bells I hear, the people all exulting,
- While follow eyes the steady keel, the vessel grim and daring; 
- But O heart! heart! heart! {.indent-3}
- O the bleeding drops of red, {.indent-4}
- Where on the deck my Captain lies, {.indent-5}
- Fallen cold and dead. {.indent-6}

elotroalex commented Feb 28, 2016

Ah, yes I know. It is a fantastic way of writing it in pandoc's Markdown. The only problem is having the lines wrap properly on small screens or big fonts, given that this produces a <p> tag for the stanza, with line ends being <br/>. We're working out the possibilities. Our ideal situation would be to be able to wrap these lines in line-blocks with hanging indentation using the syntax as-is, or the plan B, not as elegant, but elegant enough, {.foo} solution that you offer, as opposed to kramdown's. (which is at least better than kramdown's:

- O Captain! my Captain! our fearful trip is done;
- The ship has weather’d every rack, the prize we sought is won,
- The port is near, the bells I hear, the people all exulting,
- While follow eyes the steady keel, the vessel grim and daring; 
- But O heart! heart! heart! {.indent-3}
- O the bleeding drops of red, {.indent-4}
- Where on the deck my Captain lies, {.indent-5}
- Fallen cold and dead. {.indent-6}
@ickc

This comment has been minimized.

Show comment
Hide comment
@ickc

ickc Jan 23, 2017

Contributor

Another thing is the AST output: if all elements receives attributes, it will be quite annoying to read the AST where most of them contain ("",[],[]). Is it possible to suppress these?

Contributor

ickc commented Jan 23, 2017

Another thing is the AST output: if all elements receives attributes, it will be quite annoying to read the AST where most of them contain ("",[],[]). Is it possible to suppress these?

@tarleb

This comment has been minimized.

Show comment
Hide comment
@tarleb

tarleb Jan 23, 2017

Collaborator

I added attributes to all types for my huskydoc experiment, and used patterns to recover a pandoc-like API. It's a nice way to hide implementation details (e.g. the empty attributes mentioned by @ickc), but sometimes felt a bit clunky. However, it's quite possible that I was simply using them wrong.

Collaborator

tarleb commented Jan 23, 2017

I added attributes to all types for my huskydoc experiment, and used patterns to recover a pandoc-like API. It's a nice way to hide implementation details (e.g. the empty attributes mentioned by @ickc), but sometimes felt a bit clunky. However, it's quite possible that I was simply using them wrong.

@xihh87

This comment has been minimized.

Show comment
Hide comment
@xihh87

xihh87 Jan 25, 2017

For paragraph elements, the attributes can be sent to a newline of its own:

This is a paragraph where we want to aply special attributes.
{#id .class}

I think this is readable enough.

xihh87 commented Jan 25, 2017

For paragraph elements, the attributes can be sent to a newline of its own:

This is a paragraph where we want to aply special attributes.
{#id .class}

I think this is readable enough.

@ousia

This comment has been minimized.

Show comment
Hide comment
@ousia

ousia Jan 25, 2017

Contributor

@xihh87, why do you write attributes placed after the text and not before it?

I mean, the following would be more consistent with:

````{#id .class}
a = 2
````
Contributor

ousia commented Jan 25, 2017

@xihh87, why do you write attributes placed after the text and not before it?

I mean, the following would be more consistent with:

````{#id .class}
a = 2
````
@xihh87

This comment has been minimized.

Show comment
Hide comment
@xihh87

xihh87 Jan 25, 2017

@ousia code blocks are the only elements that have their attributes before and not after, images, links, headers all have attributes afterwards.

![link text](url alt-text){#id attrs}

# header {#id attrs}

I also think having the attributes at the end is more readable.

xihh87 commented Jan 25, 2017

@ousia code blocks are the only elements that have their attributes before and not after, images, links, headers all have attributes afterwards.

![link text](url alt-text){#id attrs}

# header {#id attrs}

I also think having the attributes at the end is more readable.

@fmatheus

This comment has been minimized.

Show comment
Hide comment
@fmatheus

fmatheus Jan 25, 2017

fmatheus commented Jan 25, 2017

@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21
Collaborator

mb21 commented Jan 25, 2017

@ousia

This comment has been minimized.

Show comment
Hide comment
@ousia

ousia Jan 25, 2017

Contributor

@xihh87, except headings, all other elements with attributes are inline ones.

And even if headings are block elements, they may only contain a line (they aren’t a standard block element in Markdown).

Placing attributes at the beginning is clearer with multiple lines in the paragraph:

{#met-I-1}
πάντες ἄνθρωποι τοῦ εἰδέναι ὀρέγονται φύσει. σημεῖον δ᾽ ἡ τῶν αἰσθήσεων
ἀγάπησις· καὶ γὰρ χωρὶς τῆς χρείας ἀγαπῶνται δι᾽ αὑτάς, καὶ μάλιστα τῶν
ἄλλων ἡ διὰ τῶν ὀμμάτων. οὐ γὰρ μόνον ἵνα πράττωμεν ἀλλὰ καὶ μηθὲν
μέλλοντες πράττειν τὸ ὁρᾶν αἱρούμεθα ἀντὶ πάντων ὡς εἰπεῖν τῶν ἄλλων.
αἴτιον δ᾽ ὅτι μάλιστα ποιεῖ γνωρίζειν ἡμᾶς αὕτη τῶν αἰσθήσεων καὶ
πολλὰς δηλοῖ διαφοράς. φύσει μὲν οὖν αἴσθησιν ἔχοντα γίγνεται τὰ ζῷα,
ἐκ δὲ ταύτης τοῖς μὲν αὐτῶν οὐκ ἐγγίγνεται μνήμη, τοῖς δ᾽ ἐγγίγνεται.
καὶ διὰ τοῦτο ταῦτα φρονιμώτερα καὶ μαθητικώτερα τῶν μὴ δυναμένων
μνημονεύειν ἐστί, φρόνιμα μὲν ἄνευ τοῦ μανθάνειν ὅσα μὴ δύναται τῶν
ψόφων ἀκούειν (οἷον μέλιττα κἂν εἴ τι τοιοῦτον ἄλλο γένος ζῴων ἔστι),
μανθάνει δ᾽ ὅσα πρὸς τῇ μνήμῃ καὶ ταύτην ἔχει τὴν αἴσθησιν. τὰ μὲν οὖν
ἄλλα ταῖς φαντασίαις ζῇ καὶ ταῖς μνήμαις, ἐμπειρίας δὲ μετέχει μικρόν·
τὸ δὲ τῶν ἀνθρώπων γένος καὶ τέχνῃ καὶ λογισμοῖς. γίγνεται δ᾽ ἐκ τῆς
μνήμης ἐμπειρία τοῖς ἀνθρώποις· αἱ γὰρ πολλαὶ μνῆμαι τοῦ αὐτοῦ
πράγματος μιᾶς ἐμπειρίας δύναμιν ἀποτελοῦσιν.

Because you don’t need to search at the end of the paragraph which the attributes are (if any), it is clearer for both the reader and the writer.

Both SGML and XML place attributes for both inline and block elements in the opening tag (never in the closing one).

@fmatheus, consider that headings must contained in only one line. This is required only for this block element.

Contributor

ousia commented Jan 25, 2017

@xihh87, except headings, all other elements with attributes are inline ones.

And even if headings are block elements, they may only contain a line (they aren’t a standard block element in Markdown).

Placing attributes at the beginning is clearer with multiple lines in the paragraph:

{#met-I-1}
πάντες ἄνθρωποι τοῦ εἰδέναι ὀρέγονται φύσει. σημεῖον δ᾽ ἡ τῶν αἰσθήσεων
ἀγάπησις· καὶ γὰρ χωρὶς τῆς χρείας ἀγαπῶνται δι᾽ αὑτάς, καὶ μάλιστα τῶν
ἄλλων ἡ διὰ τῶν ὀμμάτων. οὐ γὰρ μόνον ἵνα πράττωμεν ἀλλὰ καὶ μηθὲν
μέλλοντες πράττειν τὸ ὁρᾶν αἱρούμεθα ἀντὶ πάντων ὡς εἰπεῖν τῶν ἄλλων.
αἴτιον δ᾽ ὅτι μάλιστα ποιεῖ γνωρίζειν ἡμᾶς αὕτη τῶν αἰσθήσεων καὶ
πολλὰς δηλοῖ διαφοράς. φύσει μὲν οὖν αἴσθησιν ἔχοντα γίγνεται τὰ ζῷα,
ἐκ δὲ ταύτης τοῖς μὲν αὐτῶν οὐκ ἐγγίγνεται μνήμη, τοῖς δ᾽ ἐγγίγνεται.
καὶ διὰ τοῦτο ταῦτα φρονιμώτερα καὶ μαθητικώτερα τῶν μὴ δυναμένων
μνημονεύειν ἐστί, φρόνιμα μὲν ἄνευ τοῦ μανθάνειν ὅσα μὴ δύναται τῶν
ψόφων ἀκούειν (οἷον μέλιττα κἂν εἴ τι τοιοῦτον ἄλλο γένος ζῴων ἔστι),
μανθάνει δ᾽ ὅσα πρὸς τῇ μνήμῃ καὶ ταύτην ἔχει τὴν αἴσθησιν. τὰ μὲν οὖν
ἄλλα ταῖς φαντασίαις ζῇ καὶ ταῖς μνήμαις, ἐμπειρίας δὲ μετέχει μικρόν·
τὸ δὲ τῶν ἀνθρώπων γένος καὶ τέχνῃ καὶ λογισμοῖς. γίγνεται δ᾽ ἐκ τῆς
μνήμης ἐμπειρία τοῖς ἀνθρώποις· αἱ γὰρ πολλαὶ μνῆμαι τοῦ αὐτοῦ
πράγματος μιᾶς ἐμπειρίας δύναμιν ἀποτελοῦσιν.

Because you don’t need to search at the end of the paragraph which the attributes are (if any), it is clearer for both the reader and the writer.

Both SGML and XML place attributes for both inline and block elements in the opening tag (never in the closing one).

@fmatheus, consider that headings must contained in only one line. This is required only for this block element.

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Jan 26, 2017

Owner
Owner

jgm commented Jan 26, 2017

@fmatheus

This comment has been minimized.

Show comment
Hide comment
@fmatheus

fmatheus Jan 26, 2017

fmatheus commented Jan 26, 2017

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Jan 26, 2017

Owner
Owner

jgm commented Jan 26, 2017

@xihh87

This comment has been minimized.

Show comment
Hide comment
@xihh87

xihh87 Jan 26, 2017

xihh87 commented Jan 26, 2017

@ousia

This comment has been minimized.

Show comment
Hide comment
@ousia

ousia Jan 27, 2017

Contributor
  • for block elements, attribute comes immediately before,
    and on a line by itself

Of course, we've already followed a different path with
headers and code blocks, as noted.

@jgm, do you you really think that the first example is inherently more readable than the second one:

{#met-I-1}
> πάντες ἄνθρωποι τοῦ εἰδέναι ὀρέγονται φύσει. 
> {#met-I-1}
> πάντες ἄνθρωποι τοῦ εἰδέναι ὀρέγονται φύσει. 

I mean, having an attributes referring to the element in the next line may be easier to be parsed (I simply don’t know), but attributes belong to elements. Writing them before the opening characters doesn’t seem to me especially clear for reading.

Of course, we've already followed a different path with
headers and code blocks, as noted.

Will the way of marking the attribute for these two block elements remain the same after all elements are granted attributes?

Contributor

ousia commented Jan 27, 2017

  • for block elements, attribute comes immediately before,
    and on a line by itself

Of course, we've already followed a different path with
headers and code blocks, as noted.

@jgm, do you you really think that the first example is inherently more readable than the second one:

{#met-I-1}
> πάντες ἄνθρωποι τοῦ εἰδέναι ὀρέγονται φύσει. 
> {#met-I-1}
> πάντες ἄνθρωποι τοῦ εἰδέναι ὀρέγονται φύσει. 

I mean, having an attributes referring to the element in the next line may be easier to be parsed (I simply don’t know), but attributes belong to elements. Writing them before the opening characters doesn’t seem to me especially clear for reading.

Of course, we've already followed a different path with
headers and code blocks, as noted.

Will the way of marking the attribute for these two block elements remain the same after all elements are granted attributes?

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Jan 27, 2017

Owner
Owner

jgm commented Jan 27, 2017

@ousia

This comment has been minimized.

Show comment
Hide comment
@ousia

ousia Feb 2, 2017

Contributor

I mean, having an attributes referring to the element in the next line
may be easier to be parsed (I simply don’t know), but attributes belong
to elements. Writing them before the opening characters doesn’t seem to
me especially clear for reading.

I don't find that, myself. And anyway, writing it before
the opening > is essential if you want to distinguish
between the case where the attribute is on the blockquote
and the case where it's on the first paragraph inside
the blockquote.

I overlooked it was side-marking. What would happen with proper division syntax?

I mean, do you really think that the first sample is more readable than the second one?

{#metaphysics-greek}
:::
πάντες ἄνθρωποι τοῦ εἰδέναι ὀρέγονται φύσει. 

ὅτι μὲν οὖν ἡ σοφία περί τινας ἀρχὰς καὶ αἰτίας ἐστὶν ἐπιστήμη, δῆλον.
:::
::: {#metaphysics-greek}
πάντες ἄνθρωποι τοῦ εἰδέναι ὀρέγονται φύσει. 

ὅτι μὲν οὖν ἡ σοφία περί τινας ἀρχὰς καὶ αἰτίας ἐστὶν ἐπιστήμη, δῆλον.
:::

At least for me, the second is clearer that the first sample.

Contributor

ousia commented Feb 2, 2017

I mean, having an attributes referring to the element in the next line
may be easier to be parsed (I simply don’t know), but attributes belong
to elements. Writing them before the opening characters doesn’t seem to
me especially clear for reading.

I don't find that, myself. And anyway, writing it before
the opening > is essential if you want to distinguish
between the case where the attribute is on the blockquote
and the case where it's on the first paragraph inside
the blockquote.

I overlooked it was side-marking. What would happen with proper division syntax?

I mean, do you really think that the first sample is more readable than the second one?

{#metaphysics-greek}
:::
πάντες ἄνθρωποι τοῦ εἰδέναι ὀρέγονται φύσει. 

ὅτι μὲν οὖν ἡ σοφία περί τινας ἀρχὰς καὶ αἰτίας ἐστὶν ἐπιστήμη, δῆλον.
:::
::: {#metaphysics-greek}
πάντες ἄνθρωποι τοῦ εἰδέναι ὀρέγονται φύσει. 

ὅτι μὲν οὖν ἡ σοφία περί τινας ἀρχὰς καὶ αἰτίας ἐστὶν ἐπιστήμη, δῆλον.
:::

At least for me, the second is clearer that the first sample.

@stroobandt

This comment has been minimized.

Show comment
Hide comment
@stroobandt

stroobandt Feb 3, 2017

Having asked for universal element attributes early on, I would like to chime in.
I tend to agree with @ousia and others, that the syntax for such a feature needs to be chosen with care and I applaud their constructive comments.

Personally, I feel one should try to mimic the way inline CSS classes and IDs are defined in (X)HTML; that is right besides (and inside) of the element declaring tag.

After all, that part of the Pandoc audience who are interested in this new feature, probably are so because they have CSS and (X)HTML in the back of their mind. —At least, I do!—

Finally, here is a Pandoc Markdown excerpt where I would potentially employ element attributes, possibly nested. There is a heading, a hyperlink, that is actually an image, and the hyperlink is also part of a the definition term to definition data. This is why I think the suggestion @ousia makes more sense.

#Win-Test
[![Win-Test](../images/win-test.png)](http://www.win-test.com/)Win-Test
:   The story behind [Win-Test](http://www.win-test.com/) is absolutely fascinating. Win-Test appears to be developed by a handful of French rocket scientists who, in their 35-hour work week, apparently had too much time on their hands waiting for the next rocket launch.

EDIT: Personally, I use Pandoc in many other use cases besides XHTML; anything from writing formal letters and scientific papers in LaTeX to technical reports and contracts in ConTeXt. Only in these use cases, for me personally, I would probably be less compelled to use element attributes —but I certainly would not exclude it. Things should work fine independently of the intended Pandoc use case.

stroobandt commented Feb 3, 2017

Having asked for universal element attributes early on, I would like to chime in.
I tend to agree with @ousia and others, that the syntax for such a feature needs to be chosen with care and I applaud their constructive comments.

Personally, I feel one should try to mimic the way inline CSS classes and IDs are defined in (X)HTML; that is right besides (and inside) of the element declaring tag.

After all, that part of the Pandoc audience who are interested in this new feature, probably are so because they have CSS and (X)HTML in the back of their mind. —At least, I do!—

Finally, here is a Pandoc Markdown excerpt where I would potentially employ element attributes, possibly nested. There is a heading, a hyperlink, that is actually an image, and the hyperlink is also part of a the definition term to definition data. This is why I think the suggestion @ousia makes more sense.

#Win-Test
[![Win-Test](../images/win-test.png)](http://www.win-test.com/)Win-Test
:   The story behind [Win-Test](http://www.win-test.com/) is absolutely fascinating. Win-Test appears to be developed by a handful of French rocket scientists who, in their 35-hour work week, apparently had too much time on their hands waiting for the next rocket launch.

EDIT: Personally, I use Pandoc in many other use cases besides XHTML; anything from writing formal letters and scientific papers in LaTeX to technical reports and contracts in ConTeXt. Only in these use cases, for me personally, I would probably be less compelled to use element attributes —but I certainly would not exclude it. Things should work fine independently of the intended Pandoc use case.

@thriveth

This comment has been minimized.

Show comment
Hide comment
@thriveth

thriveth Feb 3, 2017

thriveth commented Feb 3, 2017

@ickc

This comment has been minimized.

Show comment
Hide comment
@ickc

ickc Feb 3, 2017

Contributor

My use case for attributes is not (X)HTML, but being able to more easily
write my scientific papers in Pandoc's markdown. Being able to set
attributes would mean one could use e.g. the custom table and figure
environments of some journals while still writing pandoc that would
export valid HTML and, not least, to be able to minimize the manual work
in .tex files, ideally eliminate it completely (it is already almost
possible with Scholdoc, but that has its own problems).

Agree.

Since you mention Scholdoc, I personally think the biggest problem it has is that it takes the shortcut. So by design pandoc is a "Universal markup converter" that concerns all markups (it supports). Many issues in the design of pandoc might disappeared if one restricts the attention to only a few formats.

And it's related to this issue: I think if all elements are granted attributes, it will be easier for 3rd parties to build on top of pandoc rather than forking pandoc. I didn't study Scholdoc in details to see what's necessary to implements all of its features as a filter/custom reader&writer though.

Contributor

ickc commented Feb 3, 2017

My use case for attributes is not (X)HTML, but being able to more easily
write my scientific papers in Pandoc's markdown. Being able to set
attributes would mean one could use e.g. the custom table and figure
environments of some journals while still writing pandoc that would
export valid HTML and, not least, to be able to minimize the manual work
in .tex files, ideally eliminate it completely (it is already almost
possible with Scholdoc, but that has its own problems).

Agree.

Since you mention Scholdoc, I personally think the biggest problem it has is that it takes the shortcut. So by design pandoc is a "Universal markup converter" that concerns all markups (it supports). Many issues in the design of pandoc might disappeared if one restricts the attention to only a few formats.

And it's related to this issue: I think if all elements are granted attributes, it will be easier for 3rd parties to build on top of pandoc rather than forking pandoc. I didn't study Scholdoc in details to see what's necessary to implements all of its features as a filter/custom reader&writer though.

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Feb 4, 2017

Owner
Owner

jgm commented Feb 4, 2017

@thriveth

This comment has been minimized.

Show comment
Hide comment
@thriveth

thriveth Feb 4, 2017

thriveth commented Feb 4, 2017

@stroobandt

This comment has been minimized.

Show comment
Hide comment
@stroobandt

stroobandt Feb 4, 2017

@thriveth Just to make sure there are no misunderstandings; I am not proposing any raw (X)HTML for adding attributes to elements.

All I am trying to convey is that putting attribute declarations on the same line, immediately after block element declarations in Pandoc, may feel more natural to people who also know (X)HTML. Putting attributes on a line immediately above of block element declaration would probably be less so and might perhaps lead to nesting issues/confusion. Anyhow, this needs to be tested with convoluted Pandoc Markdown examples like the one I gave in my previous posting.

I totally respect users who do not use (X)HTML. As a matter of fact, personally, I employ Pandoc to produce a wide array of documents in LaTeX or ConTeXt.

stroobandt commented Feb 4, 2017

@thriveth Just to make sure there are no misunderstandings; I am not proposing any raw (X)HTML for adding attributes to elements.

All I am trying to convey is that putting attribute declarations on the same line, immediately after block element declarations in Pandoc, may feel more natural to people who also know (X)HTML. Putting attributes on a line immediately above of block element declaration would probably be less so and might perhaps lead to nesting issues/confusion. Anyhow, this needs to be tested with convoluted Pandoc Markdown examples like the one I gave in my previous posting.

I totally respect users who do not use (X)HTML. As a matter of fact, personally, I employ Pandoc to produce a wide array of documents in LaTeX or ConTeXt.

@thriveth

This comment has been minimized.

Show comment
Hide comment
@thriveth

thriveth Feb 4, 2017

@stroobandt I apologize, I did not express myself very well. The last part of my former comment was really with pandoc-crossref in mind, but that was not what we were talking about in this thread. Sorry for the confusion and derailing caused by this.

I think the point I wanted to convey was that attributes on general elements could be useful beyond the (X)HTML+CSS use case, e.g. in building specialized writers or templates or whatever for e.g. Journal-specific LaTeX classes etc.

thriveth commented Feb 4, 2017

@stroobandt I apologize, I did not express myself very well. The last part of my former comment was really with pandoc-crossref in mind, but that was not what we were talking about in this thread. Sorry for the confusion and derailing caused by this.

I think the point I wanted to convey was that attributes on general elements could be useful beyond the (X)HTML+CSS use case, e.g. in building specialized writers or templates or whatever for e.g. Journal-specific LaTeX classes etc.

@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Feb 26, 2017

Collaborator

If I understand @mpickering's proposal correctly, view patterns could help us by providing syntactic sugar for pattern matching on a data type that is only defined by a typeclass.

We could change e.g. CodeBlock Attr String to Attr a => CodeBlock a String, which would leave different readers, writers, filters etc. free to use different concrete data type implementations for attributes (e.g. one using the current (String, [String], [(String, String)]) while others use a Hashmap or GADTs or whatnot). Maybe something along the lines of:

class Attr a where
  ident  :: a -> String
  cls    :: a -> [String]
  lookup :: String -> a -> String
  asPair :: a -> (String, [String], [(String, String)])

What I still fail to understand is how exactly view pattern would help us here (I'll sit down and experiment if I find the time), because from what I can see view patterns help us with sum types, but Attr is a product type.

Collaborator

mb21 commented Feb 26, 2017

If I understand @mpickering's proposal correctly, view patterns could help us by providing syntactic sugar for pattern matching on a data type that is only defined by a typeclass.

We could change e.g. CodeBlock Attr String to Attr a => CodeBlock a String, which would leave different readers, writers, filters etc. free to use different concrete data type implementations for attributes (e.g. one using the current (String, [String], [(String, String)]) while others use a Hashmap or GADTs or whatnot). Maybe something along the lines of:

class Attr a where
  ident  :: a -> String
  cls    :: a -> [String]
  lookup :: String -> a -> String
  asPair :: a -> (String, [String], [(String, String)])

What I still fail to understand is how exactly view pattern would help us here (I'll sit down and experiment if I find the time), because from what I can see view patterns help us with sum types, but Attr is a product type.

@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Feb 27, 2017

Collaborator

This would allow for relatively straightforward refactors, for example from

blockToHtml opts (CodeBlock (ident,cls,kvs) rawCode) = do
  ...

to

blockToHtml opts (CodeBlock attr rawCode) = do
  let (ident,cls,kvs) = asPair attr
  ...
Collaborator

mb21 commented Feb 27, 2017

This would allow for relatively straightforward refactors, for example from

blockToHtml opts (CodeBlock (ident,cls,kvs) rawCode) = do
  ...

to

blockToHtml opts (CodeBlock attr rawCode) = do
  let (ident,cls,kvs) = asPair attr
  ...
@stevekm

This comment has been minimized.

Show comment
Hide comment
@stevekm

stevekm Mar 2, 2017

Not sure if this is the right place to ask this, but I am trying to customize the interactive elements that are added when converting R Markdown to HTML, specifically the 'tabsets' and floating table of contents. For example, if I wanted to adjust the color of the text in the floating table of contents, I can add CSS to my R Markdown, like this:

---
title: "Untitled"
output:
  html_document:
    keep_md: true
    css: styles.css
    toc: true
    toc_float: true
    number_sections: true

---
<style type="text/css">
#TOC {
  color: purple; 
}

</style>

example output here

I also want to change to colors of the highlighted item in the floating ToC and tab-buttons the same way. But I have not been able to find any documentation on how to access these features. Is this kind of customization available? I know that if I specify a theme in my YAML header, all the elements change color, so there must be a setting somewhere that I can access via CSS inline in the Markdown, right?

stevekm commented Mar 2, 2017

Not sure if this is the right place to ask this, but I am trying to customize the interactive elements that are added when converting R Markdown to HTML, specifically the 'tabsets' and floating table of contents. For example, if I wanted to adjust the color of the text in the floating table of contents, I can add CSS to my R Markdown, like this:

---
title: "Untitled"
output:
  html_document:
    keep_md: true
    css: styles.css
    toc: true
    toc_float: true
    number_sections: true

---
<style type="text/css">
#TOC {
  color: purple; 
}

</style>

example output here

I also want to change to colors of the highlighted item in the floating ToC and tab-buttons the same way. But I have not been able to find any documentation on how to access these features. Is this kind of customization available? I know that if I specify a theme in my YAML header, all the elements change color, so there must be a setting somewhere that I can access via CSS inline in the Markdown, right?

@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Mar 2, 2017

Collaborator

@stevekm No, this is not the right place. Use the pandoc-discuss mailing list for pandoc-related questions. Not sure where the best place for R markdown questions is.

Collaborator

mb21 commented Mar 2, 2017

@stevekm No, this is not the right place. Use the pandoc-discuss mailing list for pandoc-related questions. Not sure where the best place for R markdown questions is.

@stevekm

This comment has been minimized.

Show comment
Hide comment
@stevekm

stevekm Mar 2, 2017

@mb21 R Markdown is using pandoc, are these elements not generated by it?

stevekm commented Mar 2, 2017

@mb21 R Markdown is using pandoc, are these elements not generated by it?

@ickc

This comment has been minimized.

Show comment
Hide comment
@ickc

ickc Mar 2, 2017

Contributor

@stevekm

Not sure if this is the right place to ask this

It cannot be more wrong:

  1. the title is "Permit adding attributes to all Markdown elements". And if you don't know what that means you can read the original post. And then you'll find that it is totally unrelated to what you asked.

  2. Not only it does not fall in this issue, it won't be an "issue" on GitHub (pandoc community does not use the issue tracker as forum, a mistake I made in the past).

  3. Regarding to

    R Markdown is using pandoc, are these elements not generated by it?

    Will it fall in pandoc-discuss? You can try. What @mb21 is saying is, while Rmarkdown uses pandoc, it is not pure pandoc markdown, and people here generally do not know what Rmarkdown added/changed. If I were you, I might start talking to the Rmarkdown people first.

Contributor

ickc commented Mar 2, 2017

@stevekm

Not sure if this is the right place to ask this

It cannot be more wrong:

  1. the title is "Permit adding attributes to all Markdown elements". And if you don't know what that means you can read the original post. And then you'll find that it is totally unrelated to what you asked.

  2. Not only it does not fall in this issue, it won't be an "issue" on GitHub (pandoc community does not use the issue tracker as forum, a mistake I made in the past).

  3. Regarding to

    R Markdown is using pandoc, are these elements not generated by it?

    Will it fall in pandoc-discuss? You can try. What @mb21 is saying is, while Rmarkdown uses pandoc, it is not pure pandoc markdown, and people here generally do not know what Rmarkdown added/changed. If I were you, I might start talking to the Rmarkdown people first.

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Mar 3, 2017

Owner
Owner

jgm commented Mar 3, 2017

@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 Jun 12, 2017

Collaborator

The longer I think about a new attribute type, the more I favour a simple solution. What distinguishes attributes from first-class fields in the pandoc ADT (e.g. like the level number for Header)? It's mostly that they are optional and often not filled in, so a hypothetical record type would consist of a lot of Maybes. They also serve the function to bind any extra information to the element to be used e.g. in filters (that's why I'm still in favour of adding Attr to all elements). So maybe going with a practical solution like the following is the best we can do:

data Attr = Attr String [String] (M.Map String String)

Finally, we could add some (lens-like) functions to Builder to construct / modify attributes and discourage direct use of the type which would make future changes to it easier...

Collaborator

mb21 commented Jun 12, 2017

The longer I think about a new attribute type, the more I favour a simple solution. What distinguishes attributes from first-class fields in the pandoc ADT (e.g. like the level number for Header)? It's mostly that they are optional and often not filled in, so a hypothetical record type would consist of a lot of Maybes. They also serve the function to bind any extra information to the element to be used e.g. in filters (that's why I'm still in favour of adding Attr to all elements). So maybe going with a practical solution like the following is the best we can do:

data Attr = Attr String [String] (M.Map String String)

Finally, we could add some (lens-like) functions to Builder to construct / modify attributes and discourage direct use of the type which would make future changes to it easier...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment