chore: enforce consistent Markdown style for strong and emphasis (#37787)
This commit is contained in:
David Sanders
GitHub
parent
f7c6545eab
commit
4415b7638a
23 changed files with 66 additions and 68 deletions
|
|
@ -23,7 +23,5 @@
|
|||
"br_spaces": 0
|
||||
},
|
||||
"single-h1": false,
|
||||
"no-inline-html": false,
|
||||
"emphasis-style": false,
|
||||
"strong-style": false
|
||||
"no-inline-html": false
|
||||
}
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ _If an issue has been closed and you still feel it's relevant, feel free to ping
|
|||
|
||||
### Languages
|
||||
|
||||
We accept issues in *any* language.
|
||||
We accept issues in _any_ language.
|
||||
When an issue is posted in a language besides English, it is acceptable and encouraged to post an English-translated copy as a reply.
|
||||
Anyone may post the translated reply.
|
||||
In most cases, a quick pass through translation software is sufficient.
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ Calling `event.preventDefault()` will prevent the default behavior, which is
|
|||
terminating the application.
|
||||
|
||||
**Note:** If application quit was initiated by `autoUpdater.quitAndInstall()`,
|
||||
then `before-quit` is emitted *after* emitting `close` event on all windows and
|
||||
then `before-quit` is emitted _after_ emitting `close` event on all windows and
|
||||
closing them.
|
||||
|
||||
**Note:** On Windows, this event will not be emitted if the app is closed due
|
||||
|
|
|
|||
|
|
@ -595,7 +595,7 @@ Emitted when the window is being moved to a new position.
|
|||
|
||||
Emitted once when the window is moved to a new position.
|
||||
|
||||
__Note__: On macOS this event is an alias of `move`.
|
||||
**Note**: On macOS this event is an alias of `move`.
|
||||
|
||||
#### Event: 'enter-full-screen'
|
||||
|
||||
|
|
|
|||
|
|
@ -115,7 +115,7 @@ The following additional roles are available on _macOS_:
|
|||
* `moveTabToNewWindow` - Map to the `moveTabToNewWindow` action.
|
||||
* `window` - The submenu is a "Window" menu.
|
||||
* `help` - The submenu is a "Help" menu.
|
||||
* `services` - The submenu is a ["Services"](https://developer.apple.com/documentation/appkit/nsapplication/1428608-servicesmenu?language=objc) menu. This is only intended for use in the Application Menu and is *not* the same as the "Services" submenu used in context menus in macOS apps, which is not implemented in Electron.
|
||||
* `services` - The submenu is a ["Services"](https://developer.apple.com/documentation/appkit/nsapplication/1428608-servicesmenu?language=objc) menu. This is only intended for use in the Application Menu and is _not_ the same as the "Services" submenu used in context menus in macOS apps, which is not implemented in Electron.
|
||||
* `recentDocuments` - The submenu is an "Open Recent" menu.
|
||||
* `clearRecentDocuments` - Map to the `clearRecentDocuments` action.
|
||||
* `shareMenu` - The submenu is [share menu][ShareMenu]. The `sharingItem` property must also be set to indicate the item to share.
|
||||
|
|
|
|||
|
|
@ -317,7 +317,7 @@ name, no matter what label you set. To change it, modify your app bundle's
|
|||
[About Information Property List Files][AboutInformationPropertyListFiles]
|
||||
for more information.
|
||||
|
||||
## Setting Menu for Specific Browser Window (*Linux* *Windows*)
|
||||
## Setting Menu for Specific Browser Window (_Linux_ _Windows_)
|
||||
|
||||
The [`setMenu` method][setMenu] of browser windows can set the menu of certain
|
||||
browser windows.
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ quality, it is recommended to include at least the following sizes in the:
|
|||
* 64x64 (200% DPI scale)
|
||||
* 256x256
|
||||
|
||||
Check the *Size requirements* section in [this article][icons].
|
||||
Check the _Size requirements_ section in [this article][icons].
|
||||
|
||||
[icons]: https://learn.microsoft.com/en-us/windows/win32/uxguide/vis-icons
|
||||
|
||||
|
|
|
|||
|
|
@ -660,8 +660,8 @@ The `proxyBypassRules` is a comma separated list of rules described below:
|
|||
Match all hostnames that match the pattern HOSTNAME_PATTERN.
|
||||
|
||||
Examples:
|
||||
"foobar.com", "*foobar.com", "*.foobar.com", "*foobar.com:99",
|
||||
"https://x.*.y.com:99"
|
||||
"foobar.com", "\*foobar.com", "\*.foobar.com", "\*foobar.com:99",
|
||||
"https://x.\*.y.com:99"
|
||||
|
||||
* `"." HOSTNAME_SUFFIX_PATTERN [ ":" PORT ]`
|
||||
|
||||
|
|
|
|||
|
|
@ -25,9 +25,9 @@ app.whenReady().then(() => {
|
|||
})
|
||||
```
|
||||
|
||||
__Platform Considerations__
|
||||
**Platform Considerations**
|
||||
|
||||
__Linux__
|
||||
**Linux**
|
||||
|
||||
* Tray icon uses [StatusNotifierItem](https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/)
|
||||
by default, when it is not available in user's desktop environment the
|
||||
|
|
@ -58,14 +58,14 @@ app.whenReady().then(() => {
|
|||
})
|
||||
```
|
||||
|
||||
__MacOS__
|
||||
**MacOS**
|
||||
|
||||
* Icons passed to the Tray constructor should be [Template Images](native-image.md#template-image).
|
||||
* To make sure your icon isn't grainy on retina monitors, be sure your `@2x` image is 144dpi.
|
||||
* If you are bundling your application (e.g., with webpack for development), be sure that the file names are not being mangled or hashed. The filename needs to end in Template, and the `@2x` image needs to have the same filename as the standard image, or MacOS will not magically invert your image's colors or use the high density image.
|
||||
* 16x16 (72dpi) and 32x32@2x (144dpi) work well for most icons.
|
||||
|
||||
__Windows__
|
||||
**Windows**
|
||||
|
||||
* It is recommended to use `ICO` icons to get best visual effects.
|
||||
|
||||
|
|
|
|||
|
|
@ -1948,36 +1948,36 @@ Shows pop-up dictionary that searches the selected word on the page.
|
|||
|
||||
#### `contents.isOffscreen()`
|
||||
|
||||
Returns `boolean` - Indicates whether *offscreen rendering* is enabled.
|
||||
Returns `boolean` - Indicates whether _offscreen rendering_ is enabled.
|
||||
|
||||
#### `contents.startPainting()`
|
||||
|
||||
If *offscreen rendering* is enabled and not painting, start painting.
|
||||
If _offscreen rendering_ is enabled and not painting, start painting.
|
||||
|
||||
#### `contents.stopPainting()`
|
||||
|
||||
If *offscreen rendering* is enabled and painting, stop painting.
|
||||
If _offscreen rendering_ is enabled and painting, stop painting.
|
||||
|
||||
#### `contents.isPainting()`
|
||||
|
||||
Returns `boolean` - If *offscreen rendering* is enabled returns whether it is currently painting.
|
||||
Returns `boolean` - If _offscreen rendering_ is enabled returns whether it is currently painting.
|
||||
|
||||
#### `contents.setFrameRate(fps)`
|
||||
|
||||
* `fps` Integer
|
||||
|
||||
If *offscreen rendering* is enabled sets the frame rate to the specified number.
|
||||
If _offscreen rendering_ is enabled sets the frame rate to the specified number.
|
||||
Only values between 1 and 240 are accepted.
|
||||
|
||||
#### `contents.getFrameRate()`
|
||||
|
||||
Returns `Integer` - If *offscreen rendering* is enabled returns the current frame rate.
|
||||
Returns `Integer` - If _offscreen rendering_ is enabled returns the current frame rate.
|
||||
|
||||
#### `contents.invalidate()`
|
||||
|
||||
Schedules a full repaint of the window this web contents is in.
|
||||
|
||||
If *offscreen rendering* is enabled invalidates the frame and generates a new
|
||||
If _offscreen rendering_ is enabled invalidates the frame and generates a new
|
||||
one through the `'paint'` event.
|
||||
|
||||
#### `contents.getWebRTCIPHandlingPolicy()`
|
||||
|
|
@ -2118,7 +2118,7 @@ The zoom factor is the zoom percent divided by 100, so 300% = 3.0.
|
|||
An `Integer` property that sets the frame rate of the web contents to the specified number.
|
||||
Only values between 1 and 240 are accepted.
|
||||
|
||||
Only applicable if *offscreen rendering* is enabled.
|
||||
Only applicable if _offscreen rendering_ is enabled.
|
||||
|
||||
#### `contents.id` _Readonly_
|
||||
|
||||
|
|
|
|||
|
|
@ -821,7 +821,7 @@ It is also not emitted during in-page navigation, such as clicking anchor links
|
|||
or updating the `window.location.hash`. Use `did-navigate-in-page` event for
|
||||
this purpose.
|
||||
|
||||
Calling `event.preventDefault()` does __NOT__ have any effect.
|
||||
Calling `event.preventDefault()` does **NOT** have any effect.
|
||||
|
||||
### Event: 'will-frame-navigate'
|
||||
|
||||
|
|
@ -843,7 +843,7 @@ It is also not emitted during in-page navigation, such as clicking anchor links
|
|||
or updating the `window.location.hash`. Use `did-navigate-in-page` event for
|
||||
this purpose.
|
||||
|
||||
Calling `event.preventDefault()` does __NOT__ have any effect.
|
||||
Calling `event.preventDefault()` does **NOT** have any effect.
|
||||
|
||||
### Event: 'did-start-navigation'
|
||||
|
||||
|
|
|
|||
|
|
@ -8,8 +8,8 @@ Example Use Case:
|
|||
* We need `VS15.9` and we have `VS15.7` installed; this would require us to update an Azure image.
|
||||
|
||||
1. Identify the image you wish to modify.
|
||||
* In [appveyor.yml](https://github.com/electron/electron/blob/main/appveyor.yml), the image is identified by the property *image*.
|
||||
* The names used correspond to the *"images"* defined for a build cloud, eg the [libcc-20 cloud](https://windows-ci.electronjs.org/build-clouds/8).
|
||||
* In [appveyor.yml](https://github.com/electron/electron/blob/main/appveyor.yml), the image is identified by the property _image_.
|
||||
* The names used correspond to the _"images"_ defined for a build cloud, eg the [libcc-20 cloud](https://windows-ci.electronjs.org/build-clouds/8).
|
||||
* Find the image you wish to modify in the build cloud and make note of the **VHD Blob Path** for that image, which is the value for that corresponding key.
|
||||
* You will need this URI path to copy into a new image.
|
||||
* You will also need the storage account name which is labeled in AppVeyor as the **Disk Storage Account Name**
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ machine you can monitor compile jobs as they flow through the goma system.
|
|||
For security and cost reasons, access to Electron's Goma cluster is currently restricted
|
||||
to Electron Maintainers. If you want access please head to `#access-requests` in
|
||||
Slack and ping `@goma-squad` to ask for access. Please be aware that being a
|
||||
maintainer does not *automatically* grant access and access is determined on a
|
||||
maintainer does not _automatically_ grant access and access is determined on a
|
||||
case by case basis.
|
||||
|
||||
## Uptime / Support
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ unfriendly.
|
|||
|
||||
Contributors are encouraged to solve issues collaboratively and help one
|
||||
another make progress. If you encounter an issue that you feel is invalid, or
|
||||
which contains incorrect information, explain *why* you feel that way with
|
||||
which contains incorrect information, explain _why_ you feel that way with
|
||||
additional supporting context, and be willing to be convinced that you may
|
||||
be wrong. By doing so, we can often reach the correct outcome faster.
|
||||
|
||||
|
|
|
|||
|
|
@ -219,7 +219,7 @@ of the area you modified in order to land. Whenever a maintainer reviews a pull
|
|||
request they may request changes. These may be small, such as fixing a typo, or
|
||||
may involve substantive changes. Such requests are intended to be helpful, but
|
||||
at times may come across as abrupt or unhelpful, especially if they do not include
|
||||
concrete suggestions on *how* to change them.
|
||||
concrete suggestions on _how_ to change them.
|
||||
|
||||
Try not to be discouraged. If you feel that a review is unfair, say so or seek
|
||||
the input of another project contributor. Often such comments are the result of
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
||||
|
|
|
|||
|
|
@ -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)".
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue