Ship goldmark-attributes extension

[mestaritonttu]

This goldmark parser extension adds support for block attributes in markdown

https://github.com/mdigger/goldmark-attributes

Would it be OK to ship it or should it be reimplemented in a different way for some reason?

[bep]

Would it be OK to ship it or should it be reimplemented in a different way for some reason?

There is also a third option, and since CommonMark has spent a decade discussing this and @yuin did not add this to his implementation, maybe that's the most sensible option.

[mirenbz]

Is there any way to have this working somehow at the moment?

[bep]

Trying to ping @yuin and get his opinion; I agree that it would be really useful to be able to add CSS classes to blockquotes etc. My take on this is that the CommonMark people will never agree on a spec for this, so if we look pass the "political side" of this issue; is there a technical reason why we would not want to add this?

{.epigraph}
> Why, you may take the most gallant sailor, the most intrepid airman or the
> most audacious soldier, put them at a table together – what do you get? The
> sum of their fears.

[jmooring]

If this is added at some point, I hope it is disabled by default. Not because I don't like the idea (I do), but because separation of content and style seems like the right starting point for most projects.

[markup.goldmark.extensions]
  attributes = false

EDIT: I forgot that we already (by default) allow attributes on headings, controlled by:

[markup.goldmark.parser]
  attribute = true

which allows you to set the element id, CSS classes, and additional attributes (e.g., style, data-foo, etc.). And I'm not sure the default should be true. Additionally, would an attributes extension allow setting element id, CSS classes, and additional attributes, or would it be limited to CSS classes only?

[bep]

. Additionally, would an attributes extension allow setting element id, CSS classes, and additional attributes, or would it be limited to CSS classes only?

The linked extension above is very low on tests/documentation, so it's hard to tell. But if we want to add this to Hugo, I suspect we would need to re-implement it, so ... up to us. But I also do agree that this would be an option -- default off.

[yuin]

I agree with @bep 's opinion.
Reasons why I wont to add general attributes to the goldmark core:

1. It can be implemented (mostly) as an extension.

   • It is hard to implement heading attributes as an extension, so I've implemented it in the core.

2. There are many interpretations for attributes positions and I do not know which is the best.

   1. Attribute is in one line above an element:

      {.class}
      > foo
      > bar
      

   2. Attribute is in one line below an element:

      > foo
      > bar
      {.class}
      

      1. Special case: blockquote can be:

      > foo
      > bar
      > {.class}
      

      2. (There may be other special cases)

3. Some elements do not have suitable syntax for attributes:

   1. Lists
   2. Table cells

[jmooring]

If all three (element id, CSS classes, and additional attributes) were possible, I would vote to control them separately. Something like:

[markup.goldmark.extensions]
  attributes = true
  [markup.goldmark.extensions.attributes]
     elementIDs = false
     cssClasses = true
     additionalAttributes = false

The additionalAttributes should be limited an "allow list". And at some point someone will ask for an "allow list" for cssClasses as well.

This is one of those features that has a high risk of scope creep.

[bep]

OK, reading the Goldmark code now, I notice the new parser.WithAttribute option that is currently only available for titles (ref. discussion above); that does support any attributes and I assume it is the same parser that is used in the extension above.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.