Corrected the confusion of steps in the document due to formatting

[normal-coder]

Summary

Resolves #224

improve Logging documentation. The main changes are as follows:

• Added language settings for code blocks
• Fixed wrong numbering of operation steps caused by indentation
• Corrected heading hierarchy for first paragraph

The following is a comparison example before and after restoration:

Before:

After:

Reference from specification:

• MD009/no-trailing-spaces
• MD010/no-hard-tabs
• MD012/no-multiple-blanks
• MD029/ol-prefix
• MD031/blanks-around-fences
• MD032/blanks-around-lists
• MD034/no-bare-urls
• MD040/fenced-code-language

Release Note

None.

Documentation

This PR implements the doc change.

[netlify]

✅ Deploy Preview for docssigstore ready!

Name	Link
🔨 Latest commit	2dbd8e6
🔍 Latest deploy log	https://app.netlify.com/sites/docssigstore/deploys/64e3c01b39ece9000872a550
😎 Deploy Preview	https://deploy-preview-220--docssigstore.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[smythp]

Hi @normal-coder,

I just looked through this and it seems like a great PR.

One question I have is with the indentation of fenced (```) code blocks, for example the go and yml code blocks. Why are they indented by four spaces?

For example, I would expect:

```go
...
```

instead of:

    ```go
     ...
     ```

This doesn't seem to affect rendering, but I'd typically expect fenced code blocks to not be indented.

Thanks, this seems like a great contribution.

[smythp]

Also @ltagliaferri , this PR seems to be post-migration and doesn't need to be rebased.

[normal-coder]

Hi @normal-coder,

I just looked through this and it seems like a great PR.

One question I have is with the indentation of fenced (```) code blocks, for example the go and yml code blocks. Why are they indented by four spaces?

For example, I would expect:

...

instead of:

```go
 ...
 ```

This doesn't seem to affect rendering, but I'd typically expect fenced code blocks to not be indented.

Thanks, this seems like a great contribution.

Perhaps you should try to understand principle of uniformity of the CommonMark specification: if a chunk of text has a certain meaning, it will continue to have the same meaning when put into a container block (such as a list item or blockquote).

I can understand that coding preferences don't want to have too many spaces in front of the example code snippets (which is extremely unfriendly to Vim or Emacs users), but compared to blockquotes inserting > at the beginning of the line, it maintains the integrity and coherence of the code sex.

Such writing does not affect rendering, because most parsers follow this specification for processing and implementation.

[smythp]

In addition to reviewing the markdown, I've tested these changes with a screen reader. The change to the heading hierarchy and to list contiguity improves accessibility. Previously, the steps were treated as seven separate lists, not one list with seven items (for example). Consistency in headings is also important for screen reader navigation.

I learned a lot reading through the spec doc you shared. Semantically, how you've done things here now makes sense to me. The code blocks are indented to show that they are part of the list item, and also to indicate that the list should not be interrupted in parsing. Thanks for the explanation.