Fix rendering of nested lists in docs

Author: adamkudrna

RELEASING.md

@@ -12,9 +12,9 @@ In order for the automation to work properly, contributors must follow the
 1. Pull requests are automatically labelled by branch name. Labels are then used
    for:
 
-   1. resolving next [semantic version number][semver]
-      (BREAKING.FEATURE.PATCH),
-   2. grouping changes in changelog.
+    1. resolving next [semantic version number][semver]
+       (BREAKING.FEATURE.PATCH),
+    2. grouping changes in changelog.
 
 2. Release draft with changelog is generated as pull requests are merged into
    the `master` branch. Invididual PR names are listed and grouped by type based
@@ -30,35 +30,36 @@ See the source of `.github/workflows` for details.
    [GitHub releases page][gh-releases] to see what the changelog looks like and
    what will be the next version number.
 
-   **Don't edit manually until you are ready to publish the release.** Release
-   draft is automatically overwritten everytime a change is merged to `master`.
+    **Don't edit manually until you are ready to publish the release.** Release
+    draft is automatically overwritten everytime a change is merged to `master`.
 
 2. **Manual:** once you are ready to publish a release:
 
-   1. **Bump the version number** in `package.json` and `package-lock.json`.
-      Make sure it matches the intended version number in the release draft.
-      **Don't combine this step with any other changes,** they wouldn't be
-      reflected in the changelog.
+    1. **Bump the version number** in `package.json` and `package-lock.json`.
+       Make sure it matches the intended version number in the release draft.
+       **Don't combine this step with any other changes,** they wouldn't be
+       reflected in the changelog.
 
-   2. Now is also your **chance to review and adjust (if necessary) the intended
-      version and actual changelog before the release is published.**
-      Automatic release drafting is skipped when a version change in
-      `package.json` is  detected so this time your changes will not be
-      overwritten. Save your changes in release draft with the _Save draft_
-      button, **do not publish** yet!
+    2. Now is also your **chance to review and adjust (if necessary) the
+       intended
+       version and actual changelog before the release is published.**
+       Automatic release drafting is skipped when a version change in
+       `package.json` is  detected so this time your changes will not be
+       overwritten. Save your changes in release draft with the _Save draft_
+       button, **do not publish** yet!
 
-   3. Get back to the repository, commit both files as
-      `Bump version to <VERSION_NUMBER>` in `release/<VERSION_NUMBER>` branch,
-      create a pull request, hold your breath, and—merge it.
+    3. Get back to the repository, commit both files as
+       `Bump version to <VERSION_NUMBER>` in `release/<VERSION_NUMBER>` branch,
+       create a pull request, hold your breath, and—merge it.
 
 3. **Automatic:** once the release pull request from step 2.3 is merged, the
    following actions are triggered automatically:
 
-   1. GitHub release draft with name corresponding to the version number from
-      step 2 is published.
-   2. Git tag with the version number from step 2 is added to `master` branch.
-   3. Package is built and published to npm package registry.
-   4. Documentation is built and deployed to production.
+    1. GitHub release draft with name corresponding to the version number from
+       step 2 is published.
+    2. Git tag with the version number from step 2 is added to `master` branch.
+    3. Package is built and published to npm package registry.
+    4. Documentation is built and deployed to production.
 
 **Note:** prefix version number with `v` everywhere except in `package.json` and
 `package-lock.json`.

src/docs/contribute/composition.md

@@ -8,16 +8,16 @@ There are several types of composition approaches.
 2. **Components with subcomponents:** subcomponents cannot exist on their own
    outside their parent components.
 
-   - **Mandatory subcomponents:** subcomponent must be used at least once in
-     order for the composition to work. E.g. `Tabs` + `TabsItem`.
+     - **Mandatory subcomponents:** subcomponent must be used at least once in
+       order for the composition to work. E.g. `Tabs` + `TabsItem`.
 
-   - **Optional subcomponents:** optional subcomponents may be used to achieve
-     special results. E.g. `FormLayout` + `FormLayoutCustomField` or `Grid` +
-     `GridSpan`.
+     - **Optional subcomponents:** optional subcomponents may be used to achieve
+       special results. E.g. `FormLayout` + `FormLayoutCustomField` or `Grid` +
+       `GridSpan`.
 
-   - **Both mandatory and optional subcomponents:** e.g. `Card` + `CardBody`
-     (mandatory) + `CardFooter` (optional), `Toolbar` + `ToolbarItem`
-     (mandatory) + `ToolbarGroup` (optional), etc.
+     - **Both mandatory and optional subcomponents:** e.g. `Card` + `CardBody`
+       (mandatory) + `CardFooter` (optional), `Toolbar` + `ToolbarItem`
+       (mandatory) + `ToolbarGroup` (optional), etc.
 
 3. **Wrappers for other components:** component is designed to wrap other
    self-contained components. E.g. `FormLayout` + form fields (`CheckboxField`,

src/docs/contribute/css.md

@@ -183,14 +183,14 @@ class.
 3. **Component's top-level HTML element must have `root` class name.**
    However, this rule has a few exceptions:
 
-   1. When the component is a subcomponent, it's usually better to use
-      subcomponent's name, e.g. `item` or `group`. This enables us to keep
-      related CSS of both the main component and its subcomponents in a single
-      file and see the big picture during development.
-
-   2. When no CSS on the root element is necessary and styling only takes place
-      once a visual modification is invoked by component props, `root` class
-      name can be omitted entirely.
+    1. When the component is a subcomponent, it's usually better to use
+       subcomponent's name, e.g. `item` or `group`. This enables us to keep
+       related CSS of both the main component and its subcomponents in a single
+       file and see the big picture during development.
+
+    2. When no CSS on the root element is necessary and styling only takes place
+       once a visual modification is invoked by component props, `root` class
+       name can be omitted entirely.
 
 4. **Modifier class names related to the current HTML element must start with
    `is`** and contain the name of the target element, e.g. `isRootLoading`