attr_list on ul/ol elements?

[heston]

I'm not sure if this is a bug, or just a lack of documentation, but it seems impossible to get att_list to apply to <ul> or <ol> elements. It can only be applied to individual <li> elements.

s = """
* Item 1
* Item 2
{: .some_list }
"""

markdown.markdown(s, extensions=['extra'])

Results in:

<ul>
    <li>Item 1</li>
    <li class="some_list">Item 2</li>
</ul>

I would have expected:

<ul class="some_list">
    <li>Item 1</li>
    <li>Item 2</li>
</ul>

Is there a way to get an attribute to apply to the whole list?

[waylan]

s = """
* Item 1
* Item 2
{: .some_list }
"""

If that results in the class being assigned to the ul, then how would you propose assigning a class to a list item? Remember that secondary lines of a list item are not required to be indented (unless they are nested block items--which we don't have here). That is a basic markdown concept defined in the original syntax rules.

The fact is, the markdown syntax has no concept of a ul or ol. They are simply implied by the fact that we have list items. How are we supposed to assign attributes to something that basically doesn't exist in the syntax?

So to answer your question: no, it is not possible to assign attributes to the list itself. Granted, being able to do so would certainly make for a better hook for CSS and Javascript. I just don't see a clear way to do so that will not veer too far from Markdown's philosophy.

The basic syntax was inspired by Maruku's Attribute List feature. How does that implementation handle lists? It isn't documented and I don't recall offhand, but that might shed some light on things.

[heston]

Intuitively, I would expect the attribute to reside on the <li> if it was defined on the same line (or on the same line as the last line of the <li> block):

* Item 1
Item 1a{: .class_on_li }
* Item 2{: .class_on_li }

However, this could conflict with inline syntax, and it does get ambiguous with nested <p> tags. Not to mention it changes the existing grammar.

Another idea is to leave the <li> attribute placement as-is, and introduce a new placement for <ul>. Something like this:

* Item 1
Item 1a
* Item 2

{: .class_on_ul }

Notice the extra blank line after the last <li>. I'm not sure of this is feasible, but I don't think it conflicts with existing syntax. It could also be used with the existing <li> placement:

* Item 1
Item 1a
* Item 2
{: .class_on_last_li }
{: .class_on_ul }

I agree this is a tricky problem. However, the inability to style <ul> and <ol> tags is a bummer.

[waylan]

Intuitively, I would expect the attribute to reside on the

if it was defined on the same line (or on the same line as the last line of the

block):

• Item 1
  Item 1a{: .class_on_li }
• Item 2{: .class_on_li }
  However, this could conflict with inline syntax, and it does get ambiguous with nested

  tags. Not to mention it changes the existing grammar.

Exactly. The syntax rules state that block level attributes must be on a new line. This breaks that model and would be non-obvious and confusing to newcomers.

Another idea is to leave the

attribute placement as-is, and introduce a new placement for

. Something like this:
• Item 1
  Item 1a
• Item 2

{: .class_on_ul }
Notice the extra blank line after the last

• . I'm not sure of this is feasible, but I don't think it conflicts with existing syntax.

Actually it does. The syntax states that block level attributes must not have a blank line before them. See Maruku's docs.

It could also be used with the existing

placement:

• Item 1
  Item 1a
• Item 2
  {: .class_on_last_li }
  {: .class_on_ul }

And if you wanted to only set attributes on the ul, but not on the li, how would you propose that work?

I agree this is a tricky problem. However, the inability to style

and
tags is a bummer.

I agree. But then again, it may help to remember what it says in the Markdown syntax rules. Specifically, the first few paragraphs under Inline HTML. Like this: "For any markup that is not covered by Markdown’s syntax, you simply use HTML itself."

[uhnomoli]

This functionality for me is really important so I played around with attribute list extension a bit and quickly added it if anyone is interested.

For syntax I chose the use of a caret in place of the colon to signify that the parent is being targeted. I also made the colon required for normal usage. I did a fair bit of testing, but I'm sure I didn't cover everything. If anyone runs into any issues with it, please let me know.

+ foo
+ bar
{: .baz }
{^ .qux }

<ul class="qux">
    <li>foo</li>
    <li class="baz">bar</li>
</ul>

[mikeyakymenko]

@Anomareh hey, tell me please, how add this extantion in my project? How use this?

[kernc]

Duplicate count here sure speaks for itself.

Kramdown, the full-featured alternative GitHub Pages use and Maruku's obsoletion notice points to, given our example:

* Item 1
* Item 2
{: .some_list }

adds .some_list to <ul>, as desired.

https://johnmacfarlane.net/babelmark2/?text=*+Item+1%0A*+Item+2%0A%7B%3A+.some_list+%7D

I don't understand the .1% ambiguous case you two agreed on. Who in their right mind enables attr_list and begins line continuations with {:?

[richard-jones]

Just to add a bit of extra information around the problems with attr_lists on list elements, you also can't apply the attributes to the li if the content of the li contains other features (like links).

Kramdown allows the following syntax:

{: .some_list}
* {:.some_list__item} [Link 1](https://example.com) 
* {:.some_list__item} [Link 2](https://example.com)

Using Python Markdown, if you place the attr_list entry at the end of the line it applies to the a tag not the li, so I'd suggest the current implementation is already ambiguous. The Kramdown interpretation makes more sense for lis because once you've declared the list item with * you then apply the attrs to it, but this isn't how the python implementation interprets it

The leading attributes before the list itself I can see is more awkward, and doesn't obviously follow the style of attr_list in all other cases. Though you could argue the the ul element is implicit before the first li and therefore it is sensibly placed. Certainly it reads well, and by supporting it we'd have some cross-compatibility with Kramdown.

[waylan]

Using Python Markdown, if you place the attr_list entry at the end of the line it applies to the a tag not the li, so I'd suggest the current implementation is already ambiguous.

Not at all. The documentation clearly states:

To define attributes for a block level element, the attribute list should be defined on the last line of the block by itself.

Therefore, an attr_list which immediately follows a link can never apply to the list item.

Admittedly, our syntax does not match Kramdown. In fact, we didn't base our syntax on Kramdown, but on the first iteration of Maruku's syntax.

Of course, if anyone would like to have support for Kramdown's syntax, then you are free to create your own third-party extension. However, I have no interest in making any changes to behavior of the existing extension.