Waylan Limberg

Upon further review, and the extensive discussion in #1906, this is being punted to be implemented via a third party theme and/or plugin. Initially I was expecting a PR to...

While I understand the motivation for making this change I do have some apprehension about accepting it. Specifically, by proposing this you have ignored the suggestion in our [contributing guidelines][1]:...

Interesting request. However, where do we draw the line on feature creep? My knee-jerk reaction is to suggest that one can subclass and/or fork the extension and use your own...

First, I will note that this is certainly not the first request to alter the markup for TOC. However, previous requests have asked for different changes (like not using a...

> Looking at my PR code at the moment, I don't see any unwanted effects, but it is possible that I may not be able to understand all the implications...

Interesting. What is the value of doing this? Specifically, what we already had works just fine, so what do we gain by making this change? We are already familiar with...

Thanks for addressing the concerns. That is helpful. Especially the following. I was not aware that that change had been made already. > Also, and probably a stronger indicator than...

There is no reason to support this in Markdown as Browsers condense multiple whitespace characters in HTML into a single space anyway. However, in HTML you can work around this...

I'm inclined to not merge this as the current capitalization matches the other classes (preprocessor, postprocessor, etc.). Anyone else have any thoughts?

So it would appear that for the least amount of change we would change `BlockProcessor => Blockprocessor`, which would result in a consist style. If we went the other way,...