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

This commit is contained in:
David Sanders 2023-04-03 04:20:10 -07:00 committed by GitHub
parent f7c6545eab
commit 4415b7638a
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
23 changed files with 66 additions and 68 deletions

View file

@ -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

View file

@ -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,

View file

@ -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:

View file

@ -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]

View file

@ -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.

View file

@ -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

View file

@ -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]

View file

@ -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, youre 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)".