From d84d84c6def74f84a9061d7d6f1f3cc64d540fa9 Mon Sep 17 00:00:00 2001 From: Anna Tomanek Date: Fri, 3 Nov 2023 14:58:09 +0100 Subject: [PATCH 1/3] Changed mdash to ndash, part 1. --- docs/examples/experiments/mermaid.md | 2 +- docs/features/index.md | 4 ++-- .../architecture/core-editor-architecture.md | 2 +- docs/framework/architecture/editing-engine.md | 20 +++++++++---------- docs/framework/contributing/code-style.md | 14 ++++++------- docs/framework/contributing/contributing.md | 4 ++-- .../git-commit-message-convention.md | 4 ++-- .../contributing/package-metadata.md | 2 +- docs/framework/index.md | 6 +++--- docs/installation/advanced/dll-builds.md | 2 +- .../getting-and-setting-data.md | 2 +- .../getting-started/predefined-builds.md | 4 ++-- .../getting-started/quick-start-other.md | 2 +- docs/installation/integrations/angular.md | 2 +- .../widgets/implementing-a-block-widget.md | 10 +++++----- .../widgets/implementing-an-inline-widget.md | 2 +- .../widgets/using-react-in-a-widget.md | 2 +- .../ckeditor4-configuration-compatibility.md | 2 +- docs/updating/migration-from-ckeditor-4.md | 4 ++-- docs/updating/update-to-35.md | 2 +- scripts/vale/styles/CKEditor/Terms.yml | 3 +++ 21 files changed, 49 insertions(+), 46 deletions(-) diff --git a/docs/examples/experiments/mermaid.md b/docs/examples/experiments/mermaid.md index f3fa334e505..e80dfcaa35e 100644 --- a/docs/examples/experiments/mermaid.md +++ b/docs/examples/experiments/mermaid.md @@ -12,7 +12,7 @@ modified_at: 2023-06-14 You can create flowcharts and diagrams in CKEditor 5 thanks to the experimental integration with the [Mermaid](https://mermaid.js.org/) library. Mermaid uses a Markdown-inspired syntax to create and dynamically modify flowcharts, Gantt diagrams, pie or quadrant charts, graphs, mindmaps, and more. -The example below lets you test creating diagrams and flowcharts right during the content creation — no more screenshots that need to be re-created and re-uploaded each time something needs a change! You can also check out a live implementation in [GitHub Writer](https://ckeditor.com/blog/github-writer-now-available-with-mermaid-support/). +The example below lets you test creating diagrams and flowcharts right during the content creation – no more screenshots that need to be re-created and re-uploaded each time something needs a change! You can also check out a live implementation in [GitHub Writer](https://ckeditor.com/blog/github-writer-now-available-with-mermaid-support/). {@snippet examples/mermaid} diff --git a/docs/features/index.md b/docs/features/index.md index 4a30308a124..6c017a4972a 100644 --- a/docs/features/index.md +++ b/docs/features/index.md @@ -59,13 +59,13 @@ Additionally, CKEditor 5 offers the {@link features/restricted-editing rest {@img assets/img/features-collaboration.png 800 CKEditor 5 collaboration features.} -You can also easily track the progress and changes done in the content with the {@link features/revision-history revision history feature} {@icon @ckeditor/ckeditor5-core/theme/icons/history.svg Revision history}. This modern and robust document versioning tool lets you create named versions, compare changes, and restore previous document versions at ease, tracking all progress — also when multiple editors work together. +You can also easily track the progress and changes done in the content with the {@link features/revision-history revision history feature} {@icon @ckeditor/ckeditor5-core/theme/icons/history.svg Revision history}. This modern and robust document versioning tool lets you create named versions, compare changes, and restore previous document versions at ease, tracking all progress – also when multiple editors work together. {@img assets/img/features-revision-history.png 800 CKEditor 5 document versioning feature.} ### Document conversion -If you need to share the document outside your team, use the {@link features/export-pdf export to PDF feature} {@icon @ckeditor/ckeditor5-export-pdf/theme/icons/exportpdf.svg Export to PDF} to produce industry standard, portable, cross-platform final files. If you need to work further on the document, choose the {@link features/export-word export to Word feature} {@icon @ckeditor/ckeditor5-export-word/theme/icons/exportword.svg Export to Word} instead — and keep your comments and changes in the resulting document, ready to be edited further. These two are accompanied by the {@link features/pagination pagination feature} {@icon @ckeditor/ckeditor5-pagination/theme/icons/arrow-up.svg Previous page}{@icon @ckeditor/ckeditor5-pagination/theme/icons/arrow-down.svg Next page}, to ensure all produced documents will always look the way they should. +If you need to share the document outside your team, use the {@link features/export-pdf export to PDF feature} {@icon @ckeditor/ckeditor5-export-pdf/theme/icons/exportpdf.svg Export to PDF} to produce industry standard, portable, cross-platform final files. If you need to work further on the document, choose the {@link features/export-word export to Word feature} {@icon @ckeditor/ckeditor5-export-word/theme/icons/exportword.svg Export to Word} instead – and keep your comments and changes in the resulting document, ready to be edited further. These two are accompanied by the {@link features/pagination pagination feature} {@icon @ckeditor/ckeditor5-pagination/theme/icons/arrow-up.svg Previous page}{@icon @ckeditor/ckeditor5-pagination/theme/icons/arrow-down.svg Next page}, to ensure all produced documents will always look the way they should. ### HTML and Markdown output diff --git a/docs/framework/architecture/core-editor-architecture.md b/docs/framework/architecture/core-editor-architecture.md index 5dde5bc0eec..3597a9bd557 100644 --- a/docs/framework/architecture/core-editor-architecture.md +++ b/docs/framework/architecture/core-editor-architecture.md @@ -246,7 +246,7 @@ command.on( 'change:value', ( evt, propertyName, newValue, oldValue ) => { command.value = true; // -> 'value has changed from undefined to true' ``` -Observables have one more feature which is widely used by the editor (especially in the UI library) — the ability to bind the value of one object's property to the value of some other property or properties (of one or more objects). This, of course, can also be processed by callbacks. +Observables have one more feature which is widely used by the editor (especially in the UI library) – the ability to bind the value of one object's property to the value of some other property or properties (of one or more objects). This, of course, can also be processed by callbacks. Assuming that `target` and `source` are observables and that used properties are observable: diff --git a/docs/framework/architecture/editing-engine.md b/docs/framework/architecture/editing-engine.md index b01a245af69..c231b4f96ad 100644 --- a/docs/framework/architecture/editing-engine.md +++ b/docs/framework/architecture/editing-engine.md @@ -18,7 +18,7 @@ The editing engine implements an MVC architecture. The shape of it is not enforc [{@img assets/img/framework-architecture-engine-diagram.png Diagram of the engine's MVC architecture.}](%BASE_PATH%/assets/img/framework-architecture-engine-diagram.png) -What you can see, are three layers: **model**, **controller** and **view**. There is one **model document** which is {@link framework/deep-dive/conversion/intro **converted**} into separate views — the [**editing view**](#editing-pipeline) and the [**data view**](#data-pipeline). These two views represent, respectively, the content that the user is editing (the DOM structure that you see in the browser) and the editor input and output data (in a format that the plugged data processor understands). Both views feature virtual DOM structures (custom, DOM-like structures) on which converters and features work and which are then **rendered** to the DOM. +What you can see, are three layers: **model**, **controller** and **view**. There is one **model document** which is {@link framework/deep-dive/conversion/intro **converted**} into separate views – the [**editing view**](#editing-pipeline) and the [**data view**](#data-pipeline). These two views represent, respectively, the content that the user is editing (the DOM structure that you see in the browser) and the editor input and output data (in a format that the plugged data processor understands). Both views feature virtual DOM structures (custom, DOM-like structures) on which converters and features work and which are then **rendered** to the DOM. The green blocks are the code introduced by editor features (plugins). These features control what changes are made to the model, how they are converted to the view and how the model needs to be changed based on fired events (the view's and model's ones). @@ -78,7 +78,7 @@ editor.model.change( writer => { ### Text attributes -Text styles such as "bold" and "italic" are kept in the model not as elements but as text attributes (think — like element attributes). The following DOM structure: +Text styles such as "bold" and "italic" are kept in the model not as elements but as text attributes (think – like element attributes). The following DOM structure: ```html

@@ -109,7 +109,7 @@ Such representation of inline text styling allows to significantly reduce the co

``` -and you have a selection before the letter `"b"` (`"Foo ^bar"`), is this position inside or outside ``? If you use [native DOM Selection](https://developer.mozilla.org/en-US/docs/Web/API/Selection), you may get both positions — one anchored in `

` and the other anchored in ``. In CKEditor 5 this position translates exactly to `"Foo ^bar"`. +and you have a selection before the letter `"b"` (`"Foo ^bar"`), is this position inside or outside ``? If you use [native DOM Selection](https://developer.mozilla.org/en-US/docs/Web/API/Selection), you may get both positions – one anchored in `

` and the other anchored in ``. In CKEditor 5 this position translates exactly to `"Foo ^bar"`. ### Selection attributes @@ -180,7 +180,7 @@ This information is then used by the features and the engine to make decisions o * To which elements the heading feature can be applied (which blocks can be turned to headings and which elements are blocks in the first place). * Which elements can be wrapped with a block quote. * Whether the bold button is enabled when the selection is in a heading (and whether the text in this heading can be bolded). -* Where the selection can be placed (which is — only in text nodes and on object elements). +* Where the selection can be placed (which is – only in text nodes and on object elements). * etc. The schema is, by default, configured by editor plugins. It is recommended that every editor feature comes with rules that enable and preconfigure it in the editor. This will make sure that the plugin user can enable it without worrying to re-configure their schema. @@ -197,7 +197,7 @@ Let's again take a look at the editing engine's architecture: [{@img assets/img/framework-architecture-engine-diagram.png Diagram of the engine's MVC architecture.}](%BASE_PATH%/assets/img/framework-architecture-engine-diagram.png) -So far, we talked about the topmost layer of this diagram — the model. The role of the model layer is to create an abstraction over the data. Its format was designed to allow storing and modifying the data in the most convenient way, while enabling implementation of complex features. Most features operate on the model (read from it and change it). +So far, we talked about the topmost layer of this diagram – the model. The role of the model layer is to create an abstraction over the data. Its format was designed to allow storing and modifying the data in the most convenient way, while enabling implementation of complex features. Most features operate on the model (read from it and change it). The view, on the other hand, is an abstract representation of the DOM structure which should be presented to the user (for editing) and which should (in most cases) represent the editor's input and output (i.e. the data returned by `editor.getData()`, the data set by `editor.setData()`, pasted content, etc.). @@ -242,7 +242,7 @@ Additionally, you can define {@link module:engine/view/element~Element#getCustom * Whether an element is a widget (added by {@link module:widget/utils~toWidget `toWidget()`}). * How an element should be marked when a [marker](#markers) highlights it. -* Whether an element belongs to a certain feature — if it is a link, progress bar, caption, etc. +* Whether an element belongs to a certain feature – if it is a link, progress bar, caption, etc. #### Non-semantic views @@ -269,8 +269,8 @@ editor.editing.view.change( writer => { There are two view writers: - * {@link module:engine/view/downcastwriter~DowncastWriter} — available in the `change()` blocks, used during downcasting the model to the view. It operates on a "semantic view" so a view structure which differentiates between different types of elements (see [Element types and custom data](#element-types-and-custom-data)). - * {@link module:engine/view/upcastwriter~UpcastWriter} — a writer to be used when pre-processing the "input" data (e.g. pasted content) which happens usually before the conversion (upcasting) to the model. It operates on ["non-semantic views"](#non-semantic-views). + * {@link module:engine/view/downcastwriter~DowncastWriter} – available in the `change()` blocks, used during downcasting the model to the view. It operates on a "semantic view" so a view structure which differentiates between different types of elements (see [Element types and custom data](#element-types-and-custom-data)). + * {@link module:engine/view/upcastwriter~UpcastWriter} – a writer to be used when pre-processing the "input" data (e.g. pasted content) which happens usually before the conversion (upcasting) to the model. It operates on ["non-semantic views"](#non-semantic-views). ### Positions @@ -365,8 +365,8 @@ Let's take a look at the diagram of the engine's MVC architecture and see where {@link framework/deep-dive/conversion/downcast#downcast-pipelines **Editing downcasting**} is a bit different process than the other two. * It takes place in the "editing pipeline" (the left branch of the diagram). -* It does not have its counterpart — there is no *editing upcasting* because all user actions are handled by editor features by listening to [view events](#observers), analyzing what happened and applying necessary changes to the model. Hence, this process does not involve conversion. -* Unlike {@link module:engine/controller/datacontroller~DataController} (which handles the *data pipeline*), {@link module:engine/controller/editingcontroller~EditingController} maintains a single instance of the {@link module:engine/view/document~Document} view document's for its entire life. Every change in the model is converted to changes in that view so changes in that view can then be rendered to the DOM (if needed — i.e. if the DOM actually differs from the view at this stage). +* It does not have its counterpart – there is no *editing upcasting* because all user actions are handled by editor features by listening to [view events](#observers), analyzing what happened and applying necessary changes to the model. Hence, this process does not involve conversion. +* Unlike {@link module:engine/controller/datacontroller~DataController} (which handles the *data pipeline*), {@link module:engine/controller/editingcontroller~EditingController} maintains a single instance of the {@link module:engine/view/document~Document} view document's for its entire life. Every change in the model is converted to changes in that view so changes in that view can then be rendered to the DOM (if needed – i.e. if the DOM actually differs from the view at this stage). ### More information diff --git a/docs/framework/contributing/code-style.md b/docs/framework/contributing/code-style.md index 9dc134db629..0df93c5319f 100644 --- a/docs/framework/contributing/code-style.md +++ b/docs/framework/contributing/code-style.md @@ -357,7 +357,7 @@ A couple of useful links: ## Visibility levels -Each class property (including methods, symbols, getters or setters) can be public, protected or private. The default visibility is public, so you should not document that a property is public — there is no need to do this. +Each class property (including methods, symbols, getters, or setters) can be public, protected, or private. The default visibility is public, so you should not document that a property is public – there is no need to do this. Additional rules apply to private properties: @@ -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. Thing 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. Thing 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. @@ -522,10 +522,10 @@ There are some special rules and tips for tests. ### Test implementation * Avoid using real timeouts. Use [fake timers](https://sinonjs.org/releases/latest/fake-timers/) instead **when possible**. Timeouts make tests really slow. -* However — do not overoptimize (especially that performance is not a priority in tests). In most cases it is completely fine (and hence recommended) to create a separate editor for every `it()`. -* We aim at having 100% coverage of *all distinctive scenarios*. Covering 100% branches in the code is not the goal here — it is a byproduct of covering real scenarios. +* However – do not overoptimize (especially that performance is not a priority in tests). In most cases it is completely fine (and hence recommended) to create a separate editor for every `it()`. +* We aim at having 100% coverage of *all distinctive scenarios*. Covering 100% branches in the code is not the goal here – it is a by-product of covering real scenarios. - Think about this — when you fix a bug by adding a parameter to an existing function call you do not affect code coverage (that line was called anyway). However, you had a bug, meaning that your test suite did not cover it. Therefore, a test must be created for that code change. + Think about this: when you fix a bug by adding a parameter to an existing function call, you do not affect code coverage (that line was called anyway). However, you had a bug, meaning that your test suite did not cover it. Therefore, a test must be created for that code change. * It should be `expect( x ).to.equal( y )`. **NOT**: ~~`expect( x ).to.be.equal( y )`~~. * When using Sinon spies, pay attention to the readability of assertions and failure messages. * Use named spies, for example: @@ -693,7 +693,7 @@ this.env; ### Acronyms and proper names -Acronyms and, partially, proper names are naturally written in uppercase. This may stand against code style rules described above — especially when there is a need to include an acronym or a proper name in a variable or class name. In such case, one should follow the following rules: +Acronyms and, partially, proper names are naturally written in uppercase. This may stand against code style rules described above – especially when there is a need to include an acronym or a proper name in a variable or class name. In such case, one should follow the following rules: * Acronyms: * All lowercase if at the beginning of the variable name: `let domError`. diff --git a/docs/framework/contributing/contributing.md b/docs/framework/contributing/contributing.md index ac06b6f0cec..e197d68d5da 100644 --- a/docs/framework/contributing/contributing.md +++ b/docs/framework/contributing/contributing.md @@ -30,7 +30,7 @@ Every package repository installs Git hooks that automatically lint and check th ### Tests -We maintain a **100% code coverage** (including code branches) and pull requests with missing tests will not be accepted. However, keep in mind that 100% is not everything — every *change* must be tested. This means that if you are fixing a bug and your patch did not change the code coverage, the change itself needs a test anyway. +We maintain a **100% code coverage** (including code branches) and pull requests with missing tests will not be accepted. However, keep in mind that 100% is not everything – every *change* must be tested. This means that if you are fixing a bug and your patch did not change the code coverage, the change itself needs a test anyway. Besides automated tests, you may be asked to create a manual test for the issue. Such manual tests let us quickly validate that the issue was really fixed and are later used during the testing phase (before a release) to make sure no regressions were created. @@ -87,7 +87,7 @@ Assuming that you would like to propose some changes, these are the steps you sh Some additional things you should keep in mind: -* Your pull request should be minimal — i.e. change only things described in the ticket. Do not squeeze unrelated changes into your pull request. +* Your pull request should be minimal – i.e. change only things described in the ticket. Do not squeeze unrelated changes into your pull request. * When making a pull request on GitHub, make sure to specify which ticket(s) your pull request resolves. It is also recommended to provide more information, like how to test the patch, issues that you encountered, decisions you had to make, known problems, etc. * Make sure you signed the [Contributor License Agreement (CLA)](#contributor-license-agreement-cla) and that tests pass. Test your changes! diff --git a/docs/framework/contributing/git-commit-message-convention.md b/docs/framework/contributing/git-commit-message-convention.md index f3a04288aca..875abd4b864 100644 --- a/docs/framework/contributing/git-commit-message-convention.md +++ b/docs/framework/contributing/git-commit-message-convention.md @@ -36,7 +36,7 @@ MINOR BREAKING CHANGE (package-name): Another breaking change if needed. Closes | --- | --- | --- | --- | | Feature | `minor` | A new feature. | Visible | | Fix | `patch` | A bug fix. Should also be used for enhancements if they do not introduce new features at the same time. | Visible | -| Other | `patch` | An enhancement — when it is neither a bug fix nor a feature. Example: public API refactoring. Use it also if you do not want to admit that it was a bug ;). | Visible | +| Other | `patch` | An enhancement – when it is neither a bug fix nor a feature. Example: public API refactoring. Use it also if you do not want to admit that it was a bug ;). | Visible | | Docs | `patch` | Updated documentation. | Hidden | | Internal | `patch` | Other kinds of internal changes. | Hidden | | Tests | `patch` | Changes in test files. | Hidden | @@ -223,7 +223,7 @@ Things like: should be checked and added if missing. -As a reviewer, remember that the message will end up in the changelog and must be understandable in a broad context of the entire editor. It is not for you — it is for other developers. +As a reviewer, remember that the message will end up in the changelog and must be understandable in a broad context of the entire editor. It is not for you – it is for other developers. When closing a PR, remember to copy the source of the message to the textarea with the merge commit message: diff --git a/docs/framework/contributing/package-metadata.md b/docs/framework/contributing/package-metadata.md index 4f4fbd42423..d185391b0fd 100644 --- a/docs/framework/contributing/package-metadata.md +++ b/docs/framework/contributing/package-metadata.md @@ -31,7 +31,7 @@ The `ckeditor5-metadata.json` file is a JSON object that holds the `plugins` arr * `uiComponents` – An array of objects that describes UI components exported by the plugin. Each object in this array may contain: * `name` – The name of the component the plugin exports. It should match the actual UI name registered by the plugin. * `type` – The component type: `Button`, `SplitButton` or `Dropdown`. - * `iconPath` – The path to the SVG icon for `Button` or `SplitButton`. The path can be either relative to the package or absolute — linking to a resource from another package. + * `iconPath` – The path to the SVG icon for `Button` or `SplitButton`. The path can be either relative to the package or absolute – linking to a resource from another package. * `label` – Text content for `Dropdown` components. * `toolbars` – An array of toolbar names that a given UI component can be added to. Some UI components may be added to multiple toolbars. * `htmlOutput` – An array of objects that defines all possible HTML elements which can be created by a given plugin. The main property in this object is `elements`. Other properties (like `classes`, `styles`, `attributes`) only apply to items defined in the `elements` property within a given object. The wildcard character `*` is used to mark any value. The full list of all these properties includes: diff --git a/docs/framework/index.md b/docs/framework/index.md index b53ccfdf975..4b27771d377 100644 --- a/docs/framework/index.md +++ b/docs/framework/index.md @@ -8,7 +8,7 @@ meta-description: Learn how to install, integrate, configure, and develop CKEdit # CKEditor 5 Framework overview -CKEditor 5 is a project that allows you to quickly and easily initialize one of the many types of editors it offers in your application. At the same time, it is a framework for creating custom-tailored rich-text editing solutions. The former requirement is met thanks to the {@link installation/getting-started/predefined-builds predefined CKEditor 5 builds}. The latter — thanks to CKEditor 5 Framework. +CKEditor 5 is a project that allows you to quickly and easily initialize one of the many types of editors it offers in your application. At the same time, it is a framework for creating custom-tailored rich-text editing solutions. The former requirement is met thanks to the {@link installation/getting-started/predefined-builds predefined CKEditor 5 builds}. The latter – thanks to CKEditor 5 Framework. CKEditor 5 Framework is a highly-flexible and universal platform that provides a set of components allowing you to create any kind of rich text editing solution. It enables the building of different, custom-tailored editors that suit specific needs. It also provides tools for the creation and integration of user-made features and for customizing existing ones. @@ -32,7 +32,7 @@ To sum up: you need to start using the framework as soon as existing builds do n The framework was designed to be a highly flexible and universal platform for creating custom rich-text editing solutions. At the same time, it meets several goals that make implementing features as easy a task as possible. -* **Plugin-based architecture.** Everything is a plugin — even such crucial features as support for typing or `

` elements. You can remove plugins or replace them with your own implementations to achieve fully customized results. +* **Plugin-based architecture.** Everything is a plugin – even such crucial features as support for typing or `

` elements. You can remove plugins or replace them with your own implementations to achieve fully customized results. * **Schema-less core.** The core makes minimal assumptions and can be controlled through the schema. This leaves all decisions to plugins and hence to you. * **Collaboration-ready.** Or rather, real-time collaboration is **ready for you to use**! The editor implements [Operational Transformation](https://en.wikipedia.org/wiki/Operational_transformation) for the tree-structured model as well as many other mechanisms which were required to create a seamless collaborative UX. Additionally, we provide cloud infrastructure and plugins enabling real-time collaborative editing in your application! {@link features/real-time-collaboration Check the collaboration demo}. * **Custom data model.** The editing engine implements a tree-structured custom data model, designed to fit multiple requirements such as enabling real-time collaboration and complex editing features (like tables or nested blocks). @@ -40,7 +40,7 @@ The framework was designed to be a highly flexible and universal platform for cr * **TypeScript.** The project is written in TypeScript and provides native type definitions. This helps create better, more reliable code that's easier to understand and maintain. * **Granular, reusable features.** Features are implemented in a granular way. This allows for reusing and recomposing them which, in turn, makes it possible to customize and extend the editor. For instance, the {@link features/images-overview image feature} consists of over 10 plugins at the moment. * **Extensibility.** The entire editor architecture was designed for maximum flexibility. The code is event-based and highly decoupled, allowing you to plug in or replace selected pieces. Features do not directly depend on one another and communicate in standardized ways. -* **A beautiful UI.** Text editing is not only about typing — your users will need a UI to create links or manage images. We believe that a proper UX needs to be carefully designed and we did not skip this part. Having second thoughts about the proposed UI? No problem at all! You can always create your custom interface for CKEditor 5 thanks to its decoupled UI. +* **A beautiful UI.** Text editing is not only about typing – your users will need a UI to create links or manage images. We believe that a proper UX needs to be carefully designed and we did not skip this part. Having second thoughts about the proposed UI? No problem at all! You can always create your custom interface for CKEditor 5 thanks to its decoupled UI. * **Quality.** All official packages have extensive test suites (100% code coverage is merely a step to that). All code has extensive {@link api/index API documentation}. * **Minimal configuration.** To avoid bloat, features have minimal configuration. Deeper changes in their behavior can be done by recomposing them with custom features. * **8+ years of support.** It is not yet another framework to be gone next year or a hyped proof-of-concept to fail in a real-life scenario. We have over 20 years of experience in creating rich-text editors and continue working day in and day out on improving your future-proof rich-text editor of choice. diff --git a/docs/installation/advanced/dll-builds.md b/docs/installation/advanced/dll-builds.md index b2c989499a4..d078bf38bf6 100644 --- a/docs/installation/advanced/dll-builds.md +++ b/docs/installation/advanced/dll-builds.md @@ -15,7 +15,7 @@ So far, the two most common integration methods included: * Using pre-compiled builds. This can be either one of the official builds or a custom build. In this case, adding a plugin requires recompiling the entire build. * Integrating the editor from source. In this case, if you want to add a plugin, your application needs to be recompiled. -In some advanced use cases, the list of available plugins cannot be limited — it should be possible to add plugins without any access to Node.js. In other words, plugins should be built (compiled) separately from the editor's core. +In some advanced use cases, the list of available plugins cannot be limited – it should be possible to add plugins without any access to Node.js. In other words, plugins should be built (compiled) separately from the editor's core. This is where the DLL builds come to the rescue. diff --git a/docs/installation/getting-started/getting-and-setting-data.md b/docs/installation/getting-started/getting-and-setting-data.md index 4de835ab579..e33bc7aa2c5 100644 --- a/docs/installation/getting-started/getting-and-setting-data.md +++ b/docs/installation/getting-started/getting-and-setting-data.md @@ -281,7 +281,7 @@ function updateStatus( editor ) { How to understand this demo: * The button changes to "Saving..." when the data is being sent to the server or there are any other pending actions (e.g. an image being uploaded). -* You will be asked whether you want to leave the page if an image is being uploaded or the data has not been saved successfully yet. You can test that by dropping a big image into the editor or changing the "HTTP server lag" to a high value (e.g. 9000ms) and clicking the "Save" button. These actions will make the editor "busy" for a longer time — try leaving the page then. +* You will be asked whether you want to leave the page if an image is being uploaded or the data has not been saved successfully yet. You can test that by dropping a big image into the editor or changing the "HTTP server lag" to a high value (e.g. 9000ms) and clicking the "Save" button. These actions will make the editor "busy" for a longer time – try leaving the page then. {@snippet installation/getting-and-setting-data/manualsave} diff --git a/docs/installation/getting-started/predefined-builds.md b/docs/installation/getting-started/predefined-builds.md index e41b5300528..4d8c03b959b 100644 --- a/docs/installation/getting-started/predefined-builds.md +++ b/docs/installation/getting-started/predefined-builds.md @@ -104,14 +104,14 @@ Once the CKEditor script is loaded, you can {@link installation/getting-started/ ### Classic editor -Classic editor is what most users traditionally learnt to associate with a rich-text editor — a toolbar with an editing area placed in a specific position on the page, usually as a part of a form that you use to submit some content to the server. +Classic editor is what most users traditionally learnt to associate with a rich-text editor – a toolbar with an editing area placed in a specific position on the page, usually as a part of a form that you use to submit some content to the server. During its initialization the editor hides the used editable element on the page and renders "instead" of it. This is why it is usually used to replace `