Normalize some documentation formatting and fix some issues

docs/src/markdown/about/contributing.md

@@ -10,23 +10,23 @@ any tier you feel comfortable with. No amount is too little. We also accept one
 
 ## Bug Reports :material-bug:
 
-1. Please **read the documentation** and **search the issue tracker** to try and find the answer to your question
-  **before** posting an issue.
+1.  Please **read the documentation** and **search the issue tracker** to try and find the answer to your question
+    **before** posting an issue.
 
-2. When creating an issue on the repository, please provide as much info as possible:
+2.  When creating an issue on the repository, please provide as much info as possible:
 
-    - Version being used.
-    - Operating system.
-    - Version of Python.
-    - Errors in console.
-    - Detailed description of the problem.
-    - Examples for reproducing the error.  You can post pictures, but if specific text or code is required to reproduce
-      the issue, please provide the text in a plain text format for easy copy/paste.
+    -   Version being used.
+    -   Operating system.
+    -   Version of Python.
+    -   Errors in console.
+    -   Detailed description of the problem.
+    -   Examples for reproducing the error.  You can post pictures, but if specific text or code is required to
+        reproduce the issue, please provide the text in a plain text format for easy copy/paste.
 
     The more info provided, the greater the chance someone will take the time to answer, implement, or fix the issue.
 
-3. Be prepared to answer questions and provide additional information if required.  Issues in which the creator refuses
-  to respond to follow up questions will be marked as stale and closed.
+3.  Be prepared to answer questions and provide additional information if required.  Issues in which the creator refuses
+    to respond to follow up questions will be marked as stale and closed.
 
 ## Reviewing Code :material-glasses:
 

docs/src/markdown/about/development.md

@@ -28,11 +28,11 @@ utilizes the Flake8 linter (with some additional plugins) to ensure code conform
 When in doubt follow the formatting hints of existing code when adding or modifying files. existing files.  Listed below
 are the modules used:
 
-- @PyCQA/flake8
-- @PyCQA/flake8-docstrings
-- @PyCQA/pep8-naming
-- @ebeweber/flake8-mutable
-- @gforcada/flake8-builtins
+-   @PyCQA/flake8
+-   @PyCQA/flake8-docstrings
+-   @PyCQA/pep8-naming
+-   @ebeweber/flake8-mutable
+-   @gforcada/flake8-builtins
 
 Flake8 can be run directly via the command line from the root of the project.
 
@@ -45,11 +45,11 @@ flake8
 Documents are in Markdown (with some additional syntax) and converted to HTML via Python Markdown and this
 extension bundle. If you would like to build and preview the documentation, you must have these packages installed:
 
-- @Python-Markdown/markdown: the Markdown parser.
-- @mkdocs/mkdocs: the document site generator.
-- @squidfunk/mkdocs-material: a material theme for MkDocs.
-- @timvink/mkdocs-git-revision-date-localized-plugin: inserts date a page was last updated.
-- @facelessuser/pymdown-extensions: this Python Markdown extension bundle.
+-   @Python-Markdown/markdown: the Markdown parser.
+-   @mkdocs/mkdocs: the document site generator.
+-   @squidfunk/mkdocs-material: a material theme for MkDocs.
+-   @timvink/mkdocs-git-revision-date-localized-plugin: inserts date a page was last updated.
+-   @facelessuser/pymdown-extensions: this Python Markdown extension bundle.
 
 These can be installed via:
 
@@ -271,15 +271,15 @@ The Emoji extension has emoji indexes generated from the source of Gemoji, Emoji
 for auto-generating these indexes.  In the case of Twemoji, it will also reference EmojiOne's short name index, so you
 may need to do both EmojiOne and Twemoji if the support is not satisfactory.
 
-1. Ensure you have Requests (@requests/requests) installed: `pip install requests`.
-2. Fork the repository and checkout to your machine.
-3. Navigate to the root of the project.
-4. Call the generator script: `python tools/gen_emoji.py --gemoji`, `python tools/gen_emoji.py --emojione`, or
-  `python tools/gen_emoji.py --twemoji`. If you already have the latest tag locally, you can specify `--no-download`. It
-  will prompt you to select a tag to download and/or use.  Please pull the latest **official** tag.  Please don't pull
-  experimental tags.  This should update the indexes.
-5. Then you want to update the tests.
-6. Force the tests to update via `python run_tests.py --update`.  Make sure only the emoji tests get updated.
+1.  Ensure you have Requests (@requests/requests) installed: `pip install requests`.
+2.  Fork the repository and checkout to your machine.
+3.  Navigate to the root of the project.
+4.  Call the generator script: `python tools/gen_emoji.py --gemoji`, `python tools/gen_emoji.py --emojione`, or
+    `python tools/gen_emoji.py --twemoji`. If you already have the latest tag locally, you can specify `--no-download`.
+    It will prompt you to select a tag to download and/or use.  Please pull the latest **official** tag.  Please don't
+    pull experimental tags.  This should update the indexes.
+5.  Then you want to update the tests.
+6.  Force the tests to update via `python run_tests.py --update`.  Make sure only the emoji tests get updated.
 
 Nothing is fool proof.  If they make a breaking change to the files that the script parses, or the location of the files
 change, the auto-update tool may need to be updated itself (hopefully this would be a rare occurrence).  If such a

docs/src/markdown/about/releases/6.0.md

@@ -1,4 +1,4 @@
-# 6.0 Migration Notes{: #\6.0}
+# 6.0 Migration Notes {: #\6.0}
 
 ## Overview
 
@@ -19,17 +19,17 @@ appropriate to define no custom fences.
 Below are instructions on how to upgrade if you were relying on the either the default settings of `custom_fences` or if
 you had written your own custom fence formatters.
 
-1. If you've written your own custom fence formatters, the number of parameters needed has changed, so you must update
-  your existing formatters.  The needed parameters are the same regardless of whether you are using an options validator
-  or not.
+1.  If you've written your own custom fence formatters, the number of parameters needed has changed, so you must update
+    your existing formatters.  The needed parameters are the same regardless of whether you are using an options
+    validator or not.
 
     ```py3
     def custom_formatter(source, language, css_class, options, md):
         return string
     ```
 
 2. `flow` and `sequence` are no longer defined by default. If you were relying on the default custom fences, you will
-  have to define them manually now. The needed settings are found below:
+    have to define them manually now. The needed settings are found below:
 
     ```py3
     extension_configs = {

docs/src/markdown/about/releases/8.0.md

@@ -4,21 +4,21 @@
 
 In general, there are a couple things to be aware of when upgrading to 8.0.
 
-- Some previously deprecated features are now removed: tabbed code blocks via SuperFences and ExtraRawHTML. These were
-  originally deprecated as they are now redundant, and information is provided to allow you to get the same behavior
-  as before.
+-   Some previously deprecated features are now removed: tabbed code blocks via SuperFences and ExtraRawHTML. These were
+    originally deprecated as they are now redundant, and information is provided to allow you to get the same behavior
+    as before.
 
-- One of the most invasive changes was adding the support of defining arbitrary attributes on code blocks in SuperFences
-  via the brace header format. This caused numerous changes that affects those who define their own custom fences. If
-  you are only using the builtin fences provided by SuperFences, you will likely notice no adverse affects, but will be
-  able to take advantage of new the new features being offered.
+-   One of the most invasive changes was adding the support of defining arbitrary attributes on code blocks in
+    SuperFences via the brace header format. This caused numerous changes that affects those who define their own custom
+    fences. If you are only using the builtin fences provided by SuperFences, you will likely notice no adverse affects,
+    but will be able to take advantage of new the new features being offered.
 
 ## Better Support for JS Highlighters
 
-- SuperFences adds the ability, when using the brace header format (` ```{.lang .class #id attr=value} `) to add
-  arbitrary HTML attributes to code blocks. By default, all classes, IDs and and attributes are added to the `code`
-  block of the generated output. The one exception is that the default `highlight` class is always added to the top
-  level element.
+-   SuperFences adds the ability, when using the brace header format (` ```{.lang .class #id attr=value} `) to add
+    arbitrary HTML attributes to code blocks. By default, all classes, IDs and and attributes are added to the `code`
+    block of the generated output. The one exception is that the default `highlight` class is always added to the top
+    level element.
 
     For instance, if a user needed to specify that a line number starts with an attribute `data-linenum-start`, they
     could simply use the brace header format to define this new attribute:
@@ -36,69 +36,71 @@ In general, there are a couple things to be aware of when upgrading to 8.0.
     attributes to configure line numbers and other highlighter specific features without the Highlight extension getting
     in the way.
 
-- Some JS highlighters may require attributes and classes to be assigned to the `pre` element, so the
-  [Highlight](../../extensions/highlight.md) extension has added a new feature called `code_attr_on_pre`. This new
-  option will ensure that custom classes, IDs, and attributes are applied to the `pre` element instead.
+-   Some JS highlighters may require attributes and classes to be assigned to the `pre` element, so the
+    [Highlight](../../extensions/highlight.md) extension has added a new feature called `code_attr_on_pre`. This new
+    option will ensure that custom classes, IDs, and attributes are applied to the `pre` element instead.
 
-- By default, JavaScript ready code blocks would normally have the specified language class prefixed with `language-`.
-  This follows the HTML 5 specification, but some highlighters may prefer something different. The prefix can now be
-  changed with the new [Highlight](../../extensions/highlight.md) option called `language_prefix`.
+-   By default, JavaScript ready code blocks would normally have the specified language class prefixed with `language-`.
+    This follows the HTML 5 specification, but some highlighters may prefer something different. The prefix can now be
+    changed with the new [Highlight](../../extensions/highlight.md) option called `language_prefix`.
 
 ## Retired Features
 
-- The legacy tab feature has been removed from SuperFences. This does not mean tab support is dead as the
-  [Tabbed](../../extensions/tabbed.md) extension actually provides an even more useful, general purpose, solution. It
-  was impossible to keep this legacy feature around, in its current implementation, after the restructure of for
-  attribute list support, so we decided to officially retire this already deprecated feature.
+-   The legacy tab feature has been removed from SuperFences. This does not mean tab support is dead as the
+    [Tabbed](../../extensions/tabbed.md) extension actually provides an even more useful, general purpose, solution. It
+    was impossible to keep this legacy feature around, in its current implementation, after the restructure of for
+    attribute list support, so we decided to officially retire this already deprecated feature.
 
-- ExtraRawHTML has officially been removed. This extension only existed because Python Markdown did not have the feature
-  exposed in a manner that allowed you to use it without including all of their "Extra" extension, now that Python
-  Markdown has exposed this extension by itself, there is no longer a reason for us expose it via ExtraRawHTML. Please
-  use Python Markdown's [`md_in_html`][md-in-html] extension instead to get the same exact functionality.
+-   ExtraRawHTML has officially been removed. This extension only existed because Python Markdown did not have the
+    feature exposed in a manner that allowed you to use it without including all of their "Extra" extension, now that
+    Python  Markdown has exposed this extension by itself, there is no longer a reason for us expose it via
+    ExtraRawHTML. Please use Python Markdown's [`md_in_html`][md-in-html] extension instead to get the same exact
+    functionality.
 
 ## Custom Fence Changes
 
 SuperFences made numerous changes so that users who wish not to use Pygments can set arbitrary attributes via the brace
 header format so that can more extensively configure their code blocks for JavaScript syntax highlighters. This required
 changes to how custom fences were handled.
 
-- Custom fence formatters are now expected to take a new keyword attribute called `attrs`. `attrs` contains a dictionary
-  of key/value pairs defining attributes that should be attached to the main block element generated by a given
-  formatter. In general, custom formatters *should* handle these, but are not required to.  At the very least, they
-  should be updated to take the argument even if they don't do anything with them. Custom fences that do not accept this
-  parameter will silently fail. If your custom fence already accepts `**kwargs` (as recommended in the 7.0 release),
-  your fence should continue to work even you do not do anything with the attributes. No use and apply the new,
-  attributes, you will have to read the `attrs` parameter and set those to one of the elements in your generated HTML.
+-   Custom fence formatters are now expected to take a new keyword attribute called `attrs`. `attrs` contains a
+    dictionary of key/value pairs defining attributes that should be attached to the main block element generated by a
+    given formatter. In general, custom formatters *should* handle these, but are not required to.  At the very least,
+    they should be updated to take the argument even if they don't do anything with them. Custom fences that do not
+    accept this parameter will silently fail. If your custom fence already accepts `**kwargs` (as recommended in the 7.0
+    release), your fence should continue to work even you do not do anything with the attributes. No use and apply the
+    new, attributes, you will have to read the `attrs` parameter and set those to one of the elements in your generated
+    HTML.
 
-- Custom fence validators have been updated to handle validation of inputs by assigning valid inputs to either an
-  `options` dictionary or an `attrs` dictionary. The new function signature looks like this:
-  `#!py3 validator(language, inputs, options, attrs, md):`.
+-   Custom fence validators have been updated to handle validation of inputs by assigning valid inputs to either an
+    `options` dictionary or an `attrs` dictionary. The new function signature looks like this:
+    `#!py3 validator(language, inputs, options, attrs, md):`.
 
-  - `inputs` contains all the parsed key/value pairs and should **never** be modified. `options` should have inputs
-    added to it that configure a formatter's features. You should parse, format and assign all inputs that are
-    considered options to the `option` dictionary.
+    -   `inputs` contains all the parsed key/value pairs and should **never** be modified. `options` should have inputs
+        added to it that configure a formatter's features. You should parse, format and assign all inputs that are
+        considered options to the `option` dictionary.
 
-  - `attrs` normally would contain copies of any non-option key/value pairs from inputs, unaltered. These would usually
-    be applied to HTML elements as attributes.
+    -   `attrs` normally would contain copies of any non-option key/value pairs from inputs, unaltered. These would
+        usually be applied to HTML elements as attributes.
 
-  - `md` is the `Markdown` class instance and is useful if you want to access meta data or anything else in your
-    validator.
+    -   `md` is the `Markdown` class instance and is useful if you want to access meta data or anything else in your
+        validator.
 
-    SuperFences will detect if you are using an older validator and should gracefully transition and use the old format,
-    but it is strongly recommended to use the new format. If you run into any issues, you are required to update to the
-    new format. In a future version, the graceful transition will be removed.
+        SuperFences will detect if you are using an older validator and should gracefully transition and use the old
+        format, but it is strongly recommended to use the new format. If you run into any issues, you are required to
+        update to the new format. In a future version, the graceful transition will be removed.
 
-- Since attributes and options are now parsed via the [`attr_list`][attr-list] extension, custom fences can no longer
-  allow inputs in the form `key=` (with no value), they must be in the form `key`, `key="value"` or `key=value`. When
-  defining an input in the form `key` (with no value), the value will be the `key` name (this is how
-  [`attr_list`][attr-list] handles such cases). To specify an empty `key`, please use `key=""`.
+-   Since attributes and options are now parsed via the [`attr_list`][attr-list] extension, custom fences can no longer
+    allow inputs in the form `key=` (with no value), they must be in the form `key`, `key="value"` or `key=value`. When
+    defining an input in the form `key` (with no value), the value will be the `key` name (this is how
+    [`attr_list`][attr-list] handles such cases). To specify an empty `key`, please use `key=""`.
 
-- If a custom validator fails, SuperFences will now gracefully handle the error and try the next custom fence in the
-  queue. If a custom formatter fails. If you suspect your custom validator is not working, you should add your own debug
-  code to your custom fence to verify whether it is failing or not.
+-   If a custom validator fails, SuperFences will now gracefully handle the error and try the next custom fence in the
+    queue. If a custom formatter fails. If you suspect your custom validator is not working, you should add your own
+    debug code to your custom fence to verify whether it is failing or not.
 
-- SuperFences will gracefully handle the error and abort processing the fence. If you suspect your custom formatter is
-  not working, you should add your own debug code to your custom fence to verify whether it is failing or not.
+-   SuperFences will gracefully handle the error and abort processing the fence. If you suspect your custom formatter is
+    not working, you should add your own debug code to your custom fence to verify whether it is failing or not.
 
 ## New Extension