chore: enforce consistent Markdown style for strong and emphasis (#37787)

docs/tutorial/boilerplates-and-clis.md

@@ -21,8 +21,8 @@ can clone and customize to your heart's content.
 
 A command line tool on the other hand continues to support you throughout the
 development and release. They are more helpful and supportive but enforce
-guidelines on how your code should be structured and built. *Especially for
-beginners, using a command line tool is likely to be helpful*.
+guidelines on how your code should be structured and built. _Especially for
+beginners, using a command line tool is likely to be helpful_.
 
 ## Electron Forge
 

docs/tutorial/electron-timelines.md

@@ -65,7 +65,7 @@ the Electron team will drop support back to the latest three stable major versio
 
 :::
 
-The latest three *stable* major versions are supported by the Electron team.
+The latest three _stable_ major versions are supported by the Electron team.
 For example, if the latest release is 6.1.x, then the 5.0.x as well
 as the 4.2.x series are supported. We only support the latest minor release
 for each stable release series. This means that in the case of a security fix,

docs/tutorial/electron-versioning.md

@@ -143,7 +143,7 @@ The `electron/electron` repository also enforces squash merging, so you only nee
 
 ## Historical versioning (Electron 1.X)
 
-Electron versions *< 2.0* did not conform to the [SemVer](https://semver.org) spec: major versions corresponded to end-user API changes, minor versions corresponded to Chromium major releases, and patch versions corresponded to new features and bug fixes. While convenient for developers merging features, it creates problems for developers of client-facing applications. The QA testing cycles of major apps like Slack, Teams, Skype, VS Code, and GitHub Desktop can be lengthy and stability is a highly desired outcome. There is a high risk in adopting new features while trying to absorb bug fixes.
+Electron versions _< 2.0_ did not conform to the [SemVer](https://semver.org) spec: major versions corresponded to end-user API changes, minor versions corresponded to Chromium major releases, and patch versions corresponded to new features and bug fixes. While convenient for developers merging features, it creates problems for developers of client-facing applications. The QA testing cycles of major apps like Slack, Teams, Skype, VS Code, and GitHub Desktop can be lengthy and stability is a highly desired outcome. There is a high risk in adopting new features while trying to absorb bug fixes.
 
 Here is an example of the 1.x strategy:
 

docs/tutorial/macos-dock.md

@@ -15,7 +15,7 @@ icon as the entry point for cross-platform features like
 The custom dock is commonly used to add shortcuts to tasks the user wouldn't
 want to open the whole app window for.
 
-__Dock menu of Terminal.app:__
+**Dock menu of Terminal.app:**
 
 ![Dock Menu][dock-menu-image]
 

docs/tutorial/offscreen-rendering.md

@@ -8,7 +8,7 @@ The offscreen rendering in Electron uses a similar approach to that of the
 [Chromium Embedded Framework](https://bitbucket.org/chromiumembedded/cef)
 project.
 
-*Notes*:
+_Notes_:
 
 * There are two rendering modes that can be used (see the section below) and only
 the dirty area is passed to the `paint` event to be more efficient.

docs/tutorial/performance.md

@@ -295,13 +295,13 @@ browsers apply to Electron's renderers, too. The two primary tools at your
 disposal  are currently `requestIdleCallback()` for small operations and
 `Web Workers` for long-running operations.
 
-*`requestIdleCallback()`* allows developers to queue up a function to be
+_`requestIdleCallback()`_ allows developers to queue up a function to be
 executed as soon as the process is entering an idle period. It enables you to
 perform low-priority or background work without impacting the user experience.
 For more information about how to use it,
 [check out its documentation on MDN][request-idle-callback].
 
-*Web Workers* are a powerful tool to run code on a separate thread. There are
+_Web Workers_ are a powerful tool to run code on a separate thread. There are
 some caveats to consider – consult Electron's
 [multithreading documentation][multithreading] and the
 [MDN documentation for Web Workers][web-workers]. They're an ideal solution

docs/tutorial/recent-documents.md

@@ -12,11 +12,11 @@ hide_title: true
 Windows and macOS provide access to a list of recent documents opened by
 the application via JumpList or dock menu, respectively.
 
-__JumpList:__
+**JumpList:**
 
 ![JumpList Recent Files][jumplist-image]
 
-__Application dock menu:__
+**Application dock menu:**
 
 ![macOS Dock Menu][dock-menu-image]
 

docs/tutorial/security.md

@@ -44,7 +44,7 @@ your responsibility to ensure that the code is not malicious.
 
 It is important to remember that the security of your Electron application is
 the result of the overall security of the framework foundation
-(*Chromium*, *Node.js*), Electron itself, all NPM dependencies and
+(_Chromium_, _Node.js_), Electron itself, all NPM dependencies and
 your code. As such, it is your responsibility to follow a few important best
 practices:
 
@@ -52,7 +52,7 @@ practices:
 When releasing your product, you’re also shipping a bundle composed of Electron,
 Chromium shared library and Node.js. Vulnerabilities affecting these components
 may impact the security of your application. By updating Electron to the latest
-version, you ensure that critical vulnerabilities (such as *nodeIntegration bypasses*)
+version, you ensure that critical vulnerabilities (such as _nodeIntegration bypasses_)
 are already patched and cannot be exploited in your application. For more information,
 see "[Use a current version of Electron](#16-use-a-current-version-of-electron)".