More quotes and punctuation fixes. And other fixes.

SECURITY.md

@@ -7,4 +7,4 @@ When reporting a suspected security problem, please bear this in mind:
 *   Make sure to provide as many details as possible about the vulnerability.
 *   Please do not disclose publicly any security issues until we fix them and publish security releases.
 
-Contact the security team at [email protected]. As soon as we receive the security report, we'll work promptly to confirm the issue and then to provide a security fix.
+Contact the security team at [email protected]. As soon as we receive the security report, we will work promptly to confirm the issue and then to provide a security fix.

docs/framework/architecture/editing-engine.md

@@ -227,15 +227,15 @@ editor.data;                    // The data pipeline (DataController).
 
 ### Element types and custom data
 
-The structure of the view resembles the structure in the DOM very closely. The semantics of HTML is defined in its specification. The view structure comes "DTD-free", so in order to provide additional information and to better express the semantics of the content, the view structure implements 6 element types ({@link module:engine/view/containerelement~ContainerElement}, {@link module:engine/view/attributeelement~AttributeElement}, {@link module:engine/view/emptyelement~EmptyElement}, {@link module:engine/view/rawelement~RawElement}, {@link module:engine/view/uielement~UIElement}, and {@link module:engine/view/editableelement~EditableElement}) and so called {@link module:engine/view/element~Element#getCustomProperty "custom properties"} (i.e. custom element properties which are not rendered). This additional information provided by the editor features is then used by the {@link module:engine/view/renderer~Renderer} and [converters](#conversion).
+The structure of the view resembles the structure in the DOM very closely. The semantics of HTML is defined in its specification. The view structure comes "DTD-free," so to provide additional information and to better express the semantics of the content, the view structure implements six element types ({@link module:engine/view/containerelement~ContainerElement}, {@link module:engine/view/attributeelement~AttributeElement}, {@link module:engine/view/emptyelement~EmptyElement}, {@link module:engine/view/rawelement~RawElement}, {@link module:engine/view/uielement~UIElement}, and {@link module:engine/view/editableelement~EditableElement}) and so-called {@link module:engine/view/element~Element#getCustomProperty "custom properties"} (that is custom element properties which are not rendered). This additional information provided by the editor features is then used by the {@link module:engine/view/renderer~Renderer} and [converters](#conversion).
 
 The element types can be defined as follows:
 
 * **Container element** &ndash; The elements that build the structure of the content. Used for block elements such as `<p>`, `<h1>`, `<blockQuote>`, `<li>`, etc.
 * **Attribute element** &ndash; The elements that cannot hold container elements inside them. Most model text attributes are converted to view attribute elements. They are used mostly for inline styling elements such as `<strong>`, `<i>`, `<a>`, `<code>`. Similar attribute elements are flattened by the view writer, so e.g. `<a href="..."><a class="bar">x</a></a>` would automatically be optimized to `<a href="..." class="bar">x</a>`.
 * **Empty element** &ndash; The elements that must not have any child nodes, for example `<img>`.
 * **UI element** &ndash; The elements that are not a part of the "data" but need to be "inlined" in the content. They are ignored by the selection (it jumps over them) and the view writer in general. The contents of these elements and events coming from them are filtered out, too.
-* **Raw element** &ndash; The elements that work as data containers ("wrappers", "sandboxes") but their children are transparent to the editor. Useful when non-standard data must be rendered but the editor should not be concerned what it is and how it works. Users cannot put the selection inside a raw element, split it into smaller chunks or directly modify its content.
+* **Raw element** &ndash; The elements that work as data containers ("wrappers," "sandboxes") but their children are transparent to the editor. Useful when non-standard data must be rendered but the editor should not be concerned what it is and how it works. Users cannot put the selection inside a raw element, split it into smaller chunks or directly modify its content.
 * **Editable element** &ndash; The elements used as "nested editables" of non-editable fragments of the content, for example a caption in the image widget, where the `<figure>` wrapping the image is not editable (it is a widget) and the `<figcaption>` inside it is an editable element.
 
 Additionally, you can define {@link module:engine/view/element~Element#getCustomProperty custom properties} which may be used to store information like:
@@ -356,7 +356,7 @@ Let's take a look at the diagram of the engine's MVC architecture and see where
 
 ### Data pipeline
 
-{@link framework/deep-dive/conversion/upcast **Data upcasting**} is a process which starts in the bottom right corner of the diagram (in the view layer), passes from the data view, through a converter (green box) in the controller layer to the model document in the top right-hand corner. As you can see, it goes from the bottom to the top, hence "upcasting". Also, it is handled by the *data pipeline* (the right branch of the diagram), hence "data upcasting". Note: Data upcasting is also used to process pasted content (which is similar to loading data).
+{@link framework/deep-dive/conversion/upcast **Data upcasting**} is a process that starts in the bottom right corner of the diagram (in the view layer), passes from the data view, through a converter (green box) in the controller layer to the model document in the top right-hand corner. As you can see, it goes from the bottom to the top, hence "upcasting." Also, it is handled by the *data pipeline* (the right branch of the diagram), hence "data upcasting." Note: Data upcasting is also used to process pasted content (which is similar to loading data).
 
 {@link framework/deep-dive/conversion/downcast#downcast-pipelines **Data downcasting**} is the opposite process to *data upcasting*. It starts in the top right-hand corner and goes down to the bottom right-hand corner. Again, the name of the conversion process matches the direction and the pipeline.
 

docs/framework/contributing/code-style.md

@@ -513,8 +513,8 @@ There are some special rules and tips for tests.
 
 	Using titles like *"utils"* is not fine as there are multiple utils in the entire project. *"Table utils"* would be better.
 * Test descriptions (`it()`) should be written like documentation (what you do and what should happen), e.g. *"the foo dialog closes when the X button is clicked"*. Also, *"...case 1"*, *"...case 2"* in test descriptions are not helpful.
-* Avoid test descriptions like *"does not crash when two ranges get merged"*. Instead, explain what is actually expected to happen. For instance: *"leaves 1 range when two ranges get merged"*.
-* Most often, using words like "correctly", "works fine" is a code smell. Think about the requirements – when writing them you do not say that feature X should "work fine". You document how it should work.
+* Avoid test descriptions like *"does not crash when two ranges get merged."* Instead, explain what is actually expected to happen. For instance: *"leaves 1 range when two ranges get merged."*
+* Most often, using words like "correctly," "works fine" is a code smell. Think about the requirements – when writing them you do not say that feature X should "work fine." You document how it should work.
 * Ideally, it should be possible to recreate an algorithm just by reading the test descriptions.
 * Avoid covering multiple cases under one `it()`. It is OK to have multiple assertions in one test, but not to test e.g. how method `foo()` works when it is called with 1, then with 2, then 3, etc. There should be a separate test for each case.
 * Every test should clean after itself, including destroying all editors and removing all elements that have been added.

docs/installation/integrations/react.md

@@ -338,7 +338,7 @@ export default App;
 
 ### Vite
 
-Vite requires linked packages to be ESM, and unfortunately, the CKEditor build is not ESM yet (but we're working on it). Therefore, you must modify the `vite.config.js` file to integrate a custom build with Vite. The snippet below will allow you to include the custom build in a Vite bundle. Check out the [Vite docs](https://vitejs.dev/guide/dep-pre-bundling.html#monorepos-and-linked-dependencies) to see more details.
+Vite requires linked packages to be ESM, and unfortunately, the CKEditor build is not ESM yet (but we are working on it). Therefore, you must modify the `vite.config.js` file to integrate a custom build with Vite. The snippet below will allow you to include the custom build in a Vite bundle. Check out the [Vite documentation](https://vitejs.dev/guide/dep-pre-bundling.html#monorepos-and-linked-dependencies) for more details.
 
 ```js
 // vite.config.js

docs/installation/plugins/features-html-output-overview.md

@@ -12,9 +12,9 @@ Listed below are all official CKEditor 5 packages as well as some partner p
 
 The classes, styles or attributes applied to an HTML element are all **possible** results. It does not mean they all will always be used.
 
-`$block` is a generic structural element that may contain textual content. Features like headings or paragraph implement it to inherit common behaviours. You can read more about it in the {@link framework/deep-dive/schema#generic-items Schema} guide.
+`$block` is a generic structural element that may contain textual content. Features like headings or paragraph implement it to inherit common behaviors. You can read more about it in the {@link framework/deep-dive/schema#generic-items Schema} guide.
 
-If a given plugin does not generate any output, the "HTML output" is described as "None".  Wildcard character `*` means any value is possible.
+If a given plugin does not generate any output, the "HTML output" is described as "None."  Wildcard character `*` means any value is possible.
 
 The data used to generate the following tables comes from the package metadata. You can read more about it in the {@link framework/contributing/package-metadata package metadata} guide.
 

docs/support/license-key-and-activation.md

@@ -51,7 +51,7 @@ Follow this guide to get the license key necessary to activate your purchased pr
 
 ### Log in to the CKEditor Ecosystem dashboard
 
-Log in to the [CKEditor Ecosystem dashboard](https://dashboard.ckeditor.com). If this is the very first time you do it, you will receive a confirmation email and will be asked to create a password for your account. Keep it safe.
+Log in to the [CKEditor Ecosystem dashboard](https://dashboard.ckeditor.com). If this is the first time you do it, you will receive a confirmation email and will be asked to create a password for your account. Keep it safe.
 
 ### Access the account dashboard
 
@@ -61,7 +61,7 @@ After logging in, click "CKEditor" under the "Your products" header on the left.
 
 ### Copy the license key
 
-After clicking "Manage", you can access the license key needed to run the editor and the premium features. Note that the same license key will be valid for both the Productivity Pack and other standalone features, as well as CKEditor 5 itself.
+After clicking "Manage," you can access the license key needed to run the editor and the premium features. Note that the same license key will be valid for both the Productivity Pack and other standalone features, as well as CKEditor 5 itself.
 
 {@img assets/img/ckeditor-key.png 822 Premium features license key in the management console.}
 

docs/tutorials/abbreviation-plugin-tutorial/abbreviation-plugin-level-1.md

@@ -12,7 +12,7 @@ This guide will show you how to create a simple abbreviation plugin for CKEditor
 
 We will create a toolbar button that lets the users insert abbreviations into their document. These abbreviations will use the [`<abbr>` <abbr title="HyperText Markup Language">HTML</abbr> element](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/abbr) with a ‘title’ attribute that will show up in a tooltip when the user hovers over the element. You can check the mechanism hovering over the underlined "HTML" text in the previous sentence.
 
-This first part of the tutorial will only cover the basics. We will just insert one possible abbreviation: "WYSIWYG". We will get user input in the {@link tutorials/abbreviation-plugin-tutorial/abbreviation-plugin-level-2 next part of this tutorial series}.
+This first part of the tutorial will only cover the basics. We will just insert one possible abbreviation: "WYSIWYG." We will get user input in the {@link tutorials/abbreviation-plugin-tutorial/abbreviation-plugin-level-2 next part of this tutorial series}.
 
 If you want to see the final product of this tutorial before you plunge in, check out the [live demo](#demo).
 
@@ -244,7 +244,7 @@ Converting the full title of the abbreviation is a little bit tricky, because we
 
 In the downcast conversion, we will use one of our conversion helpers &ndash; {@link framework/deep-dive/conversion/helpers/downcast#attribute-to-element-conversion-helper `attributeToElement()`} &ndash; to transform the model abbreviation attribute into the view `<abbr>` element.
 
-We will need to use a callback function, in order to get the title stored as a model attribute value and transform it into the title value of the view element. Here, the second parameter of the view callback is the `DowncastConversionApi` object. We will use its `writer` property, which will allow us to manipulate the data during downcast conversion, as it contains an instance of the `DowncastWriter`.
+We will need to use a callback function to get the title stored as a model attribute value and transform it into the title value of the view element. Here, the second parameter of the view callback is the `DowncastConversionApi` object. We will use its `writer` property, which will allow us to manipulate the data during downcast conversion, as it contains an instance of the `DowncastWriter`.
 
 ```js
 // abbreviation/abbreviationediting.js

docs/tutorials/abbreviation-plugin-tutorial/abbreviation-plugin-level-3.md

@@ -259,11 +259,11 @@ export default class FormView extends View {
 }
 ```
 
-Our new functionality should work now, check it out yourself! It does not recognize whether the selected text is an abbreviation already, so if you select "WYSIWYG", the full title does not yet appear in the title input field. We will change it in the next steps.
+Our new functionality should work now, check it out yourself! It does not recognize whether the selected text is an abbreviation already, so if you select "WYSIWYG," the full title does not yet appear in the title input field. We will change it in the next steps.
 
 ## Adding a command
 
-Our plugin does what we want it to do, so why complicate things by adding a command? Well, a command not only executes an action, but also automatically reacts when any changes are applied to the model.
+Our plugin does what we want it to do, so why complicate things by adding a command? Well, a command not only executes an action but also automatically reacts when any changes are applied to the model.
 
 <info-box>
 	A command in CKEditor&nbsp;5 is a combination of an action and a state. The state of the command gets refreshed whenever anything changes in the model. We highly recommend {@link framework/architecture/core-editor-architecture#commands reading about commands} before we move on.
@@ -654,7 +654,7 @@ export default class AbbreviationCommand extends Command {
 
 If the collapsed selection is not inside an existing abbreviation, we will insert a text node with the "abbreviation" attribute in place of the caret.
 
-The user might place the abbreviation inside a text, which already has some other model attributes, like "bold" or "italic". We should first collect them along with our abbreviation attribute, and use the whole list when inserting the abbreviation into the document. We will use our {@link module:utils/tomap~toMap `toMap`} helper function to collect all attributes.
+The user might place the abbreviation inside a text, which already has some other model attributes, like "bold" or "italic." We should first collect them along with our abbreviation attribute, and use the whole list when inserting the abbreviation into the document. We will use our {@link module:utils/tomap~toMap `toMap`} helper function to collect all attributes.
 
 ```js
 // abbreviation/abbreviationcommand.js

docs/tutorials/widgets/implementing-a-block-widget.md

@@ -572,9 +572,9 @@ It is time to check if the simple box behaves like you would like it to. You can
 * You cannot apply a list in the title and cannot turn it into a heading (other than `<h1 class="simple-box-title">` which it is already). This is because it allows only the content that is allowed in other block elements (like paragraphs). You can, however, apply italic inside the title (because italic is allowed in other blocks).
 * The description behaves like the title, but it allows more content inside &ndash; lists and other headings.
 * If you try to select the entire simple box instance and press <kbd>Delete</kbd>, it will be deleted as a whole. The same when you copy and paste it. This is because it was marked as an `isObject` element in the schema.
-* You cannot easily select the entire simple box instance by clicking on it. Also, the cursor pointer does not change when you hover it. In other words, it seems a bit "dead". This is because you have not defined the view behavior yet.
+* You cannot easily select the entire simple box instance by clicking it. Also, the cursor pointer does not change when you hover it. In other words, it seems a bit dead. This is because you have not defined the view behavior yet.
 
-Pretty cool so far, right? With a very little code, you were able to define the behavior of your simple box plugin which maintains the integrity of these elements. The engine ensures that the user does not break these instances.
+Pretty cool so far, right? With very little code, you were able to define the behavior of your simple box plugin which maintains the integrity of these elements. The engine ensures that the user does not break these instances.
 
 See what else you can improve.
 
@@ -723,7 +723,7 @@ You can rebuild your project now and see how your simple box plugin has changed.
 
 You should observe that:
 
-* The `<section>`, `<h1>`, and `<div>` elements have the `contentEditable` attribute on them (plus some classes). This attribute tells the browser whether an element is considered "editable". Passing the element through `toWidget()` will make its content non-editable. Conversely, passing it through `toWidgetEditable()` will make its content editable again.
+* The `<section>`, `<h1>`, and `<div>` elements have the `contentEditable` attribute on them (plus some classes). This attribute tells the browser whether an element is considered editable. Passing the element through `toWidget()` will make its content non-editable. Conversely, passing it through `toWidgetEditable()` will make its content editable again.
 * You can now click the widget (the gray area) to select it. Once it is selected, it is easier to copy-paste it.
 * The widget and its nested editable regions react to hovering, selection, and focus (outline).
 

docs/tutorials/widgets/using-react-in-a-widget.md

@@ -195,7 +195,7 @@ You should see a "Hello world" application in your web browser, which might not
 
 ## Application structure
 
-Nothing warms the heart of a developer like a good "Hello world!". But you probably agree that what you created is not the most useful application and it is time to change that. In the next sections, you will create some React components and CKEditor 5 classes to bring some real logic to the application.
+Nothing warms the heart of a developer like a good "Hello world!" But you probably agree that what you created is not the most useful application and it is time to change that. In the next sections, you will create some React components and CKEditor 5 classes to bring some real logic to the application.
 
 To keep some order in the project, you will put [CKEditor classes](#ckeditor-classes) in the `/ckeditor` directory and [React components](#react-components) in the `/react` directory. [Images and CSS styles](#styles-and-assets) will land in the `/assets` directory. By the time you are finished with this tutorial, the structure of the project should look as follows: