This is great, thanks for adding!

I added it as it took me sometimes to understand that, if my top level was h2, only this level and h3 could be represented, while h1 within the middle of the document and also h4 did not show up.

What's the use case here? Do you have an example page where you would want to use this? What would the desired outcome be? Also, does this differ from

$scope: $('h1,h2,h3,h4,h5,h6')

?

Hi, I generally agree about your comments and you can add new commits to this branch. This PR was more than discuss than considering an immediate merge.

What's the use case here? Do you have an example page where you would want to use this? What would the desired outcome be?

Check this page as an example:

https://ircama.github.io/osm-carto-tutorials/tile-server-ubuntu/

Your plugin is running there.

In fact, at the end of the HTML:

  $(function() {
    var navSelector = '#toc';
    var $myNav = $(navSelector);
    Toc.init($myNav, { headings: 'h1,h2,h3,h4,h5,h6' } );
    $('body').scrollspy({
      target: navSelector,
      offset: 220
    });
  });

In the page, you can see that my top level is 2 and that I generally use one sublevel, but there are some paragraphs with an additional sublevel 4:

https://ircama.github.io/osm-carto-tutorials/tile-server-ubuntu/#install-mapnik-library-from-package

• [h2] Install Mapnik library
  • [h3] Install Mapnik library from package
  • [h3] Alternatively, install Mapnik from sources
    • [h4] Install Boost from package
    • [h4] Alternatively, install the latest version of Boost from source
    • [h4] Install HarfBuzz from source
    • [h4] Build the Mapnik library from source

You see that h4 items are present (this is thanks to { headings: 'h1,h2,h3,h4,h5,h6' }), are jointly expanded with h3 (and there is no way with this drop to do differently) and they are indented and represented with smaller font size (thanks to the auto-class naming and to the CSS).

Also, does this differ from $scope: $('h1,h2,h3,h4,h5,h6')?

Could you please make an example of this?

Let's deal with the "depth" feature request separately: #37

While I like the adding of classes to different levels to make styling easier, the customization of said class seems overkill...

Also, what's the behavior when the top-level heading in the sidebar corresponds to an <h2>? My assumption is that users would care more about the level in the table of contents than what h* it corresponds to, so I would make it more clear by using toc-nav-level-1 and toc-nav-level-2 or something like that.

While I like the adding of classes to different levels to make styling easier, the customization of said class seems overkill...

Maybe it is indead an overkill if no one is going to use the same root in other places. You can suggest a code rework or do it yourself if wanted.

Also, what's the behavior when the top-level heading in the sidebar corresponds to an <h2>? My assumption is that users would care more about the level in the table of contents than what h* it corresponds to, so I would make it more clear by using toc-nav-level-1 and toc-nav-level-2 or something like that.

If you have top level h2, h1 in the middle of the document will be always shown when setting headings: 'h1,h2,h3,h4,h5,h6', but not shown if leaving this option out.

so I would make it more clear by using toc-nav-level-1 and toc-nav-level-2 or something like that.

To make sure I got your point, would you change toc-nav-h to toc-nav-level-h?

Still not sure I understand the use case here. Feel free to open an issue if you are still interested.

Let's use the existing options object—no need to make a second one.

OK. Would you please suggest a code rework? Thanks

Mind removing the try/catch? Using it like this would swallow any errors, and therefore is definitely not something I want the documentation to encourage.

Yes, right!

Thinking it would make more sense to throw an example like this in a sandbox so that it can be interactive, and tweakable by the user.

Yes, that would be great, I did not have time to setup it.