<ol> style type based on `type` attribute

[joapuiib]

Context

I'm using a Markdown extension that allows writing different types of lists.

• Lower alphabetic: <ol type="a">
• Upper alphabetic: <ol type="A">
• Lower roman: <ol type="i">
• Upper roman: <ol type="I">

Description

The following CSS overrides the default list styles, so the first nested <ol> will always be rendered as alphabetic regarding the type attribute.

mkdocs-material/src/templates/assets/stylesheets/main/_typeset.scss

Lines 331 to 339 in c6286de

	// Nested ordered list
	ol {
	list-style-type: lower-alpha;
	// Triply nested ordered list
	ol {
	list-style-type: lower-roman;
	}
	}

Could this be set only if <ol> doesn't have a specific type?

ol, ul {
  // Nested ordered list
  ol:not([type]) { 
     list-style-type: lower-alpha;
  }

  ol, ul {
     // Triply nested ordered list 
    ol:not([type]) { 
       list-style-type: lower-roman; 
    }
  }
}

Related links

• pymdown-extensions discussion: Add extension to support letter lists
• pymdown-extensions pull request: Add fancylist extension
• pymdown-fancylists (will be removed once pymdown-extensions merges this feature).

Use Cases

For example, writing:

1. List item
2. List item
    1. List item
    2. List item
    3. List item

Will result on:

1. List item
2. List item
    a. List item
    b. List item
    c. List item

Instead of:

1. List item
2. List item
    1. List item
    2. List item
    3. List item

Which might not always be desirable.

Visuals

No response

Before submitting

• I have read and followed the change request guidelines.
• I have verified that my idea is a change request and not a bug report.
• I have ensured that, to the best of my knowledge, my idea will benefit the entire community.
• I have included relevant links to the documentation, related issues, and discussions to underline the need for my idea.

[alexvoss]

I have gone and deleted the comment because it seemed to contain a link to a dodgy website hidden behind a blt.ly link. The text around the link does not seem to have anything to do with the question, so, um, a bot? @joapuiib, perhaps also remove the link from our last comment so no one clicks on it?

[joapuiib]

I have gone and deleted the comment because it seemed to contain a link to a dodgy website hidden behind a blt.ly link. The text around the link does not seem to have anything to do with the question, so, um, a bot? @joapuiib, perhaps also remove the link from our last comment so no one clicks on it?

I've removed my comment as well. Thanks!

[alexvoss]

On the substance of your question: I see that this is getting factored into pymdownx, so IMHO it would be appropriate to support this. @squidfunk will need to make the call and has infinitely more experience with this. My view is that this could break something only in unlikely edge cases, so should be ok to change. Someone would need to have a type attribute on their ol elements but expect it to be overridden by the CSS. Hope I am not holding the wrong end of the stick there.

[facelessuser]

It is definitely something I am exploring. A simple override is all that is required to get them working. I don't think lists anywhere are getting type currently unless someone is purposely adding them manually. I'm fairly certain that if I add this extension it won't break anything and people can opt in with some CSS assuming they decide to use this extension. If Material looks for types and avoids the styles automatically, the override will not be needed and I think it will just give people options.

I am still playing around with things, but I imagine if I pull the trigger on this extension some people may disable extra list types or not use the extension. It wouldn't surprise if some people don't opt-in to extra list types because they don't want to add another plugin, they use some other list plugin for some other feature, or simply don't want to use it because their editor won't automatically highlight the new list types in Markdown.

It's an interesting idea for those who want list control, but not everyone has this need. The plan would be to only support the additional list types of both uppercased and lowercased alphatically sorted lists (a-z) and Roman numeral lists.

[facelessuser]

I guess if people want to override it now, all they need is:

.md-typeset {
  /* Override Material's list type preference. */
  ol ol[type]{
    // Nested ordered list
    list-style-type: revert-layer;

    // Triply nested ordered list
    ol[type] {
      list-style-type: revert-layer;
    }
  }
}

[facelessuser]

Actually, it is even easier (I didn't account for ul nesting).

  /* Override Material's list type preference. */
.md-typeset {
  ol[type]{
    // Nested ordered list
    list-style-type: revert-layer;
  }
}

[squidfunk]

Thanks for reporting. As mentioned, we could probably defensively scope our styles to ol:not([type]), or more specifically the list-style-type property without breaking anything. This would be the mirror of the workaround posted in #7542 (comment), that would then become obsolete. Thanks for investigating to all of you, btw!

Would somebody like to propose a PR?

[joapuiib]

Would somebody like to propose a PR?

I'll try in the next few days! Thanks you all for your feedback!

[squidfunk]

I was working on other issues and also fixed this in 68b6758. In this commit, I've also added the same fix to the list style type of ul, which can now also be explicitly set. Before, I thought I was clever and added the changes in 85d6091, but that would be a breaking change for when users have deliberately overridden list-style-type on ul or ol. The only downside is that when you use type, the defaults are not applied anymore on any layer, so all ol inside an ol with type will be numbered with 1., 2., ... I think this is fine, or could be even desired, as you're making things explicit.

[squidfunk]

Note that I used revert and not revert-layer, as we're currently not using Cascade Layers.

[facelessuser]

Note that I used revert and not revert-layer, as we're currently not using Cascade Layers.

I didn't even notice that was what I used...either way, looks great!

[squidfunk]

Released as part of 9.5.36.