8
0
Просмотр исходного кода

Merge branch 'monorepo-pending' into monorepo-docs

Marek Lewandowski 5 лет назад
Родитель
Сommit
31d92674fb

+ 2 - 2
.github/ISSUE_TEMPLATE/3-enhancement.md → .github/ISSUE_TEMPLATE/3-improvement.md

@@ -1,8 +1,8 @@
 ---
-name: "💅 Enhancement"
+name: "💅 Improvement"
 about: Improve an existing functionality.
 title: ''
-labels: type:enhancement
+labels: type:improvement
 assignees: ''
 
 ---

+ 1 - 1
.gitignore

@@ -1,7 +1,7 @@
 node_modules/
 build/
 coverage/
-packages/
+packages/*/node_modules/
 docs/api/output.json
 lerna-debug.log
 .idea

+ 1 - 1
.travis.yml

@@ -8,7 +8,7 @@ services:
 cache:
   yarn: true
 node_js:
-- "8"
+- "10"
 cache:
 - node_modules
 before_install:

+ 12 - 0
README.md

@@ -669,6 +669,18 @@ See CKEditor 5 release blog posts [on the CKEditor blog](https://ckeditor.com/bl
 	</td>
 </tr>
 
+<tr>
+	<td>
+		<a href="https://github.com/ckeditor/ckeditor5-select-all"><code>@ckeditor/ckeditor5-select-all</code></a>
+	</td>
+	<td>
+		<a href="https://www.npmjs.com/package/@ckeditor/ckeditor5-select-all"><img src="https://img.shields.io/npm/v/@ckeditor/ckeditor5-select-all.svg" alt="@ckeditor/ckeditor5-select-all npm package badge"></a>
+	</td>
+	<td>
+		The "select all" feature.
+	</td>
+</tr>
+
 <tr>
 	<td>
 		<a href="https://github.com/ckeditor/ckeditor5-special-characters"><code>@ckeditor/ckeditor5-special-characters</code></a>

+ 8 - 8
docs/assets/snippet-styles.css

@@ -93,7 +93,7 @@ It breaks CKEditor 5 (see how <p><code>[]</code></p> looks). */
 
 .demo-row__third > div {
 	padding: 2.5rem;
-	border: 1px solid rgba(0, 0, 0, 0.15);
+	border: 1px solid hsla(0, 0%, 0%, 0.15);
 }
 
 .demo-row__third:nth-of-type(2) {
@@ -114,10 +114,10 @@ It breaks CKEditor 5 (see how <p><code>[]</code></p> looks). */
 .main__notification.notice {
 	position: fixed;
 	max-width: 650px;
-	border: 1px solid #e4e4e4;
-	border-left-color: #f9c669;
+	border: 1px solid hsl(0, 0%, 89%);
+	border-left-color: hsl(38.8, 92.3%, 69.4%);
 	border-left-width: 3px;
-	box-shadow: 0 2px 6px rgba(0, 0, 0, 0.18);
+	box-shadow: 0 2px 6px hsla(0, 0%, 0%, 0.18);
 	/* override .notice class' margins and paddings */
 	padding: 20px 40px 20px 20px;
 	margin: 0;
@@ -139,7 +139,7 @@ It breaks CKEditor 5 (see how <p><code>[]</code></p> looks). */
 }
 
 .main__notification-body p {
-  margin-bottom: 0.3em;
+	margin-bottom: 0.3em;
 }
 
 .main__notification-body p:last-child {
@@ -164,7 +164,7 @@ It breaks CKEditor 5 (see how <p><code>[]</code></p> looks). */
 }
 
 .main__notification-close:hover {
-	background: #eee;
+	background: hsl(0, 0%, 93%);
 }
 
 .main__notification-close:active:focus {
@@ -245,7 +245,7 @@ https://github.com/ckeditor/ckeditor5/issues/1545 */
 #snippet-inline-editor .ck-content:not(.ck-focused),
 #snippet-balloon-editor.ck-content:not(.ck-focused),
 #snippet-balloon-block-editor.ck-content:not(.ck-focused) {
-	border: 1px solid rgba(0, 0, 0, 0.15);
+	border: 1px solid hsla(0, 0%, 0%, 0.15);
 }
 
 #snippet-inline-editor h2, #snippet-inline-editor h3 {
@@ -264,7 +264,7 @@ https://github.com/ckeditor/ckeditor5/issues/1545 */
 }
 
 #snippet-inline-editor header.ck-content h3 {
-	color: rgba(5, 22, 42, 0.59);
+	color: hsla(212, 79%, 9%, 0.59);
 	font-weight: 600;
 	font-size: 1.6rem;
 }

+ 1 - 3
docs/builds/guides/development/plugins.md

@@ -32,10 +32,8 @@ Common use cases for plugins are:
 
 Creating your own plugins is a straightforward task but it requires good knowledge about a few aspects of the CKEditor 5 development environment. The following resources are recommended as a starting point:
 
-<!--
-* The {@linkTODO framework/guides/creating-plugin Plugin development guide} in the {@link framework/index CKEditor 5 Framework} documentation.
--->
 
+* The {@link framework/guides/creating-simple-plugin Plugin development guide} in the {@link framework/index CKEditor 5 Framework} documentation.
 * The {@link framework/guides/quick-start Quick start guide} in the {@link framework/index CKEditor 5 Framework} documentation.
 * {@link builds/guides/development/custom-builds Creating custom builds} which is necessary to have your plugin included inside a CKEditor 5 build.
 

+ 1 - 3
docs/builds/guides/support/browser-compatibility.md

@@ -20,10 +20,8 @@ CKEditor 5 is currently supported in the following desktop browsers:
 	* Safari (latest stable release).
 	* Opera (latest stable release).
 	* Electron (latest stable release).
-* Good support:
 	* Edge (latest stable release). Known issues:
-		* Minor issues with selection: [1](https://github.com/ckeditor/ckeditor5-engine/issues/974), [2](https://github.com/ckeditor/ckeditor5-engine/issues/928).
-		* The editor becomes unstable when F12 developer tools are enabled.
+		* Minor issue with selection: [1](https://github.com/ckeditor/ckeditor5-engine/issues/974).
 
 Not supported yet:
 

+ 6 - 2
docs/framework/guides/architecture/ui-library.md

@@ -451,10 +451,12 @@ dropdownView.buttonView.on( 'execute', () => {
 
 ## Keystrokes and focus management
 
-_Coming soon..._
-
 The framework offers built–in classes that help manage keystrokes and focus in the UI. They are particularly useful when it comes to bringing accessibility features to the application.
 
+<info-box>
+	If you want to know how the editor handles focus under the hood and what tools make it possible, check out the {@link framework/guides/deep-dive/focus-tracking **"Deep dive into focus tracking"**} guide.
+</info-box>
+
 ### Focus tracker
 
 The {@link module:utils/focustracker~FocusTracker `FocusTracker`} class can observe a number of HTML elements and determine if one of them is focused either by the user (clicking, typing) or using the `HTMLElement.focus()` DOM method.
@@ -488,6 +490,8 @@ focusTracker.on( 'change:isFocused', ( evt, name, isFocused ) => {
 
 This information is useful when implementing a certain type of UI whose behavior depends on the focus, for example, contextual panels and floating balloons containing forms should hide when the user decides to abandon them.
 
+Learn more about the focus tracker class in the {@link framework/guides/deep-dive/focus-tracking#using-the-focustracker-class "Deep dive into focus tracking"} guide.
+
 ### Keystroke handler
 
 The {@link module:utils/keystrokehandler~KeystrokeHandler `KeystrokeHandler`} listens to the keystroke events fired by an HTML element or any of its descendants and executes pre–defined actions when the keystroke is pressed. Usually, each [view](#views) creates its own keystroke handler instance which takes care of the keystrokes fired by the elements the view has rendered.

+ 713 - 0
docs/framework/guides/contributing/code-style.md

@@ -0,0 +1,713 @@
+---
+category: framework-contributing
+order: 30
+---
+
+# Code style
+
+{@link framework/guides/contributing/development-environment CKEditor 5 development environment} has ESLint enabled both as a pre-commit hook and on CI. This means that code style issues are detected automatically. Additionally, `.editorconfig` files are present in every repository to automatically adjust your IDEs settings (if it is configured to read them).
+
+Here comes a quick summary of these rules.
+
+## General
+
+**LF for line endings**. Never use CRLF.
+
+The recommended maximum **line length is 120 characters**. It cannot exceed 140 characters.
+
+## Whitespace
+
+**No trailing spaces**. Empty lines should not contain any spaces.
+
+Whitespace **inside parenthesis** and **before and after operators**:
+
+```js
+function foo( a, b, c, d, e ) {
+	if ( a > b ) {
+		c = ( d + e ) * 2;
+	}
+}
+
+foo( bar() );
+```
+
+No whitespace for an **empty parenthesis**:
+
+```js
+const a = () => {
+	// Statements...
+};
+
+a();
+```
+
+No whitespace **before colon and semicolon**:
+
+```js
+let a, b;
+
+a( 1, 2, 3 );
+
+for ( const i = 0; i < 100; i++ ) {
+	// Statements...
+}
+```
+
+## Indentation
+
+Indentation with **tab**, for both code and comments. Never use spaces.
+
+If you want to have the code readable, set **tab** to **4 spaces** in your IDE.
+
+```js
+class Bar {
+	a() {
+		while ( b in a ) {
+			if ( b == c ) {
+				// Statements...
+			}
+		}
+	}
+}
+```
+
+**Multiple lines condition**. Use **one tab** for each line:
+
+```js
+if (
+	some != really.complex &&
+	condition || with &&
+	( multiple == lines )
+) {
+	// Statements...
+}
+
+while (
+	some != really.complex &&
+	condition || with &&
+	( multiple == lines )
+) {
+	// Statements...
+}
+```
+
+<info-box>
+	We do our best to avoid complex conditions. As a rule of thumb, we first recommend finding a way to move the complexity out of the condition, for example, to a separate function with early returns for each "sentence" in such a condition.
+
+	However, overdoing things is not good as well and sometimes such a condition can be perfectly readable (which is the ultimate goal here).
+</info-box>
+
+## Braces
+
+Braces **start at the same line** as the head statement and end aligned with it:
+
+```js
+function a() {
+	// Statements...
+}
+
+if ( a ) {
+	// Statements...
+} else if ( b ) {
+	// Statements...
+} else {
+	// Statements...
+}
+
+try {
+	// Statements...
+} catch ( e ) {
+	// Statements...
+}
+```
+
+## Blank lines
+
+The code should read like a book, so put blank lines between "paragraphs" of code. This is an open and contextual rule, but some recommendations would be to separate the following sections:
+
+* variable, class and function declarations,
+* `if()`, `for()` and similar blocks,
+* steps of an algorithm,
+* `return` statements,
+* comment sections (comments should be preceded with a blank line, but if they are the "paragraph" themselves, they should also be followed with one),
+* etc.
+
+Example:
+
+```js
+class Foo extends Plugin {
+	constructor( editor ) {
+		super( editor );
+
+		/**
+		 * Some documentation...
+		 */
+		this.foo = new Foo();
+
+		/**
+		 * Some documentation...
+		 */
+		this.isBar = false;
+	}
+
+	method( bar ) {
+		const editor = this.editor;
+		const selection = editor.model.document.selection;
+
+		for ( const range of selection.getRanges() ) {
+			const position = range.start;
+
+			if ( !position ) {
+				return false;
+			}
+
+			// At this stage this and this need to happen.
+			// We considered doing this differently, but it has its shortcomings.
+			// Refer to the tests and issue #3456 to learn more.
+
+			const result = editor.model.checkSomething( position );
+
+			if ( result ) {
+				return true;
+			}
+		}
+
+		return true;
+	}
+
+	performAlgorithm() {
+		// 1. Do things A and B.
+		this.a();
+		this.b();
+
+		// 2. Check C.
+		if ( c() ) {
+			d();
+		}
+
+		// 3. Check whether we are fine.
+		const areWeFine = 1 || 2 || 3;
+
+		this.check( areWeFine );
+
+		// 4. Finalize.
+		this.finalize( areWeFine );
+
+		return areWeFine;
+	}
+}
+```
+
+## Multi-line statements and calls
+
+Whenever there is a multi-line function call:
+
+* Put the first parameter in a new line.
+* Put every parameter in a separate line indented by one tab.
+* Put the last closing parenthesis in a new line, at the same indendation level as the beginning of the call.
+
+Examples:
+
+```js
+const myObj = new MyClass(
+	'Some long parameters',
+	'To make this',
+	'Multi line'
+);
+
+fooBar(
+	() => {
+		// Statements...
+	}
+);
+
+fooBar(
+	new MyClass(
+		'Some long parameters',
+		'To make this',
+		'Multi line'
+	)
+);
+
+fooBar(
+	'A very long string',
+	() => {
+		// ... some kind
+		// ... of a
+		// ... callback
+	},
+	5,
+	new MyClass(
+		'It looks well',
+		paramA,
+		paramB,
+		new ShortClass( 2, 3, 5 ),
+		'Even when nested'
+	)
+);
+```
+
+<info-box>
+	Note that the examples above are just showcasing how such function calls can be structured. However, it is best to avoid them.
+
+	It is generally recommended to avoid having functions that accept more than 3 arguments. Instead, it is better to wrap them in an object so all parameters can be named.
+
+	It is also recommended to split such long statements into multiple shorter ones, for example, by extracting some longer parameters to separate variables.
+</info-box>
+
+## Strings
+
+Use **single quotes**:
+
+```js
+const a = 'I\'m an example for quotes';
+```
+
+Long strings can be **concatenated with plus** (`+`):
+
+```js
+const html =
+	'Line 1\n' +
+	'Line 2\n' +
+	'Line 3';
+```
+
+or template strings can be used (note that the 2nd and 3rd line will be indented in this case):
+
+```js
+const html =
+	`Line 1
+	Line 2
+	Line 3`;
+```
+
+Strings of HTML should use indentation for readability:
+
+```js
+const html =
+	`<p>
+		<span>${ a }</span>
+	</p>`;
+```
+
+## Comments
+
+* Comments are always **preceded by a blank line**.
+* Comments start with a **capital first letter** and require a period at the end (since they are sentences).
+* There must be a **single space at the start** of the text, right after the comment token.
+
+**Block comments** (`/** ... */`) are used for **documentation only**. Asterisks are aligned with space:
+
+```js
+/**
+ * Documentation for the following method.
+ *
+ * @returns {Object} Something.
+ */
+someMethod() {
+	// Statements...
+}
+```
+
+All **other comments** use **line comments** (```//```):
+
+```js
+// A comment about the following statement.
+foo();
+
+// Multiple line comments
+// go through several
+// line comments as well.
+```
+
+**Comments related to tickets or issues** should not describe the whole issue fully. A short description should be used instead, together with the ticket number in parenthesis:
+
+```js
+// Do this otherwise because of a Safari bug. (#123)
+foo();
+```
+
+## Linting
+
+CKEditor 5 development environment uses [ESLint](https://eslint.org) and [stylelint](https://stylelint.io/).
+
+A couple of useful links:
+
+* [Disabling ESLint with inline comments](https://eslint.org/docs/2.13.1/user-guide/configuring#disabling-rules-with-inline-comments).
+* [CKEditor 5 ESLint preset](https://github.com/ckeditor/ckeditor5-dev/blob/master/packages/eslint-config-ckeditor5/.eslintrc.js) (npm: [`eslint-config-ckeditor5`](http://npmjs.com/package/eslint-config-ckeditor5)).
+* [CKEditor 5 stylelint preset](https://github.com/ckeditor/ckeditor5-dev/blob/master/packages/stylelint-config-ckeditor5/.stylelintrc) (npm: [`stylelint-config-ckeditor5`](https://www.npmjs.com/package/stylelint-config-ckeditor5)).
+
+<info-box>
+	Avoid using automatic code formatters on existing code. It is fine to automatically format code that you are editing, but you should not be changing the formatting of the code that is already written to not pollute your PRs. You should also not rely solely on automatic corrections.
+</info-box>
+
+## 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 &mdash; there is no need to do this.
+
+Additional rules apply to private properties:
+
+* The names of private and protected properties that are exposed in a class prototype (or in any other way) should be prefixed with an underscore.
+* When documenting a private variable that is not added to a class prototype (or exposed in any other way), `//` comments should be used and using `@private` is not necessary.
+* A symbol property (e.g. `this[ Symbol( 'symbolName' ) ]`) should be documented as `@property {Type} _symbolName`.
+
+Example:
+
+```js
+class Foo {
+	/**
+	 * The constructor (public, as its visibility isn't defined).
+	 */
+	constructor() {
+		/**
+		 * Public property.
+		 */
+		this.foo = 1;
+
+		/**
+		 * Protected property.
+		 *
+		 * @protected
+		 */
+		this._bar = 1;
+
+		/**
+		 * @private
+		 * @property {Number} _bom
+		 */
+		this[ Symbol( 'bom' ) ] = 1;
+	}
+
+	/**
+	 * @private
+	 */
+	_somePrivateMethod() {}
+}
+
+// Some private helper.
+//
+// @returns {Number}
+function doSomething() {
+	return 1;
+}
+```
+
+### Accessibility
+
+The table below shows the accessibility of properties:
+
+<table border="1" cellpadding="1" cellspacing="1" style="width:500px">
+	<thead>
+		<tr>
+			<th scope="row">&nbsp;</th>
+			<th scope="col">Class</th>
+			<th scope="col">Package</th>
+			<th scope="col">Subclass</th>
+			<th scope="col">World</th>
+		</tr>
+	</thead>
+	<tbody>
+		<tr>
+			<th scope="row" style="text-align: left;"><code>@public</code></th>
+			<td style="text-align:center">yes</td>
+			<td style="text-align:center">yes</td>
+			<td style="text-align:center">yes</td>
+			<td style="text-align:center">yes</td>
+		</tr>
+		<tr>
+			<th scope="row" style="text-align: left;"><code>@protected</code></th>
+			<td style="text-align:center">yes</td>
+			<td style="text-align:center">yes</td>
+			<td style="text-align:center">yes</td>
+			<td style="text-align:center">no</td>
+		</tr>
+		<tr>
+			<th scope="row" style="text-align: left;"><code>@private</code></th>
+			<td style="text-align:center">yes</td>
+			<td style="text-align:center">no</td>
+			<td style="text-align:center">no</td>
+			<td style="text-align:center">no</td>
+		</tr>
+	</tbody>
+</table>
+
+(yes – accessible, no – not accessible)
+
+For instance, a protected property is accessible from its own class in which it was defined, from its whole package, and from its subclasses (even if they are not in the same package).
+
+<info-box>
+	Protected properties and methods are often used for testability. Since tests are located in the same package as the code, they can access these properties.
+</info-box>
+
+## Getters
+
+You can use ES6 getters to simplify class API:
+
+```js
+class Position {
+	// ...
+	get offset() {
+		return this.path[ this.path.length - 1 ];
+	}
+}
+```
+
+A getter should feel like a natural property. There are several recommendations to follow when creating getters:
+
+* They should be fast.
+* They should not throw.
+* They should not change the object state.
+* They should not return new instances of an object every time (so `foo.bar == foo.bar` is true). It is OK to create a new instance for the first call and cache it if it is possible.
+
+## Order within class definition
+
+Within class definition the methods and properties should be ordered as follows:
+
+1. Constructor.
+1. Getters and setters.
+1. Iterators.
+1. Public instance methods.
+1. Public static methods.
+1. Protected instance methods.
+1. Protected static methods.
+1. Private instance methods.
+1. Private static methods.
+
+The order within each group is left for the implementor.
+
+## Tests
+
+There are some special rules and tips for tests.
+
+### Test organization
+
+* Always use an outer `describe()` in a test file. Do not allow any globals, especially hooks (`beforeEach()`, `after()`, etc.) outside the outermost `describe()`.
+* The outermost `describe()` calls should create meaningful groups, so when all tests are run together a failing TC can be identified within the code base. For example:
+
+	```js
+	describe( 'Editor', () => {
+		describe( 'constructor()', () => {
+			it( ... );
+		} );
+
+		// ...
+	} );
+	```
+
+	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"* &mdash; 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 &mdash; 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.
+
+### Test implementation
+
+* Avoid using real timeouts. Use [fake timers](https://sinonjs.org/releases/v9.0.1/fake-timers/) instead **when possible**. Timeouts make tests really slow.
+* However &mdash; 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 &mdash; it is a byproduct of covering real scenarios.
+
+	Think about this &mdash; 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 )`~~.
+
+## Naming
+
+### JavaScript code names
+
+Variables, functions, namespaces, parameters and all undocumented cases must be named in [lowerCamelCase](http://en.wikipedia.org/wiki/CamelCase):
+
+```js
+let a;
+let myLongNamedVariable = true;
+
+function foo() {}
+
+function longNamedFunction( example, longNamedParameter ) {}
+```
+
+Classes must be named in [UpperCamelCase](http://en.wikipedia.org/wiki/CamelCase):
+
+```js
+class MyClass() {}
+
+const a = new MyClass();
+```
+
+Mixins must be named in [UpperCamelCase](http://en.wikipedia.org/wiki/CamelCase), postfixed with "Mixin":
+
+```js
+const SomeMixin = {
+	method1: ...,
+	method2: ...
+};
+```
+
+Global namespacing variables must be named in [ALLCAPS](http://en.wikipedia.org/wiki/All_caps):
+
+```js
+const CKEDITOR_TRANSLATIONS = {};
+```
+
+#### Private properties and methods
+
+Private properties and methods are **prefixed with an underscore**:
+
+```js
+CKEDITOR._counter;
+something._doInternalTask();
+```
+
+#### Methods and functions
+
+Methods and functions are **almost always** verbs or actions:
+
+```js
+// Good
+execute();
+this.getNextNumber()
+
+// Bad
+this.editable();
+this.status();
+```
+
+#### Properties and variables
+
+Properties and variables are **almost always** nouns:
+
+```js
+const editor = this.editor;
+this.name;
+this.editable;
+```
+
+**Boolean properties and variables** are **always** prefixed by an auxiliary verb:
+
+```js
+this.isDirty;
+this.hasChildren;
+this.canObserve;
+this.mustRefresh;
+```
+
+### Shortcuts
+
+For local variables **commonly accepted short versions** for long names are fine:
+
+```js
+const attr, doc, el, fn, deps, err, id, args, uid, evt, env;
+```
+
+The following are **the only short versions accepted for property names**:
+
+```js
+this.lang;
+this.config;
+this.id;
+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 &mdash; 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`.
+	* Default camel case at the beginning of the class name: `class DomError`.
+	* Default camel case inside the variable or class name: `function getDomError()`.
+* Proper names:
+	* All lowercase if at the beginning of the variable: `let ckeditorError`.
+	* Original case if at the beginning of the class name: `class CKEditorError`.
+	* Original case inside the variable or class name: `function getCKEditorError()`.
+
+However, two-letter acronyms and proper names (if originally written uppercase) should be uppercase. So e.g. `getUI` (not `getUi`).
+
+<info-box>
+	Two most frequently used acronyms which cause problems:
+
+	* **DOM** &ndash; It should be e.g. `getDomNode()`,
+	* **HTML** &ndash; It should be e.g. `toHtml()`.
+</info-box>
+
+### CSS classes
+
+CSS class naming pattern is based on [BEM](https://en.bem.info/) methodology and code style. All names are in lowercase with an optional dash (`-`) between the words.
+
+Top–level building **blocks** begin with a mandatory `ck-` prefix:
+
+```css
+.ck-dialog
+.ck-toolbar
+.ck-dropdown-menu
+```
+
+**Elements** belonging to the block namespace are delimited by double underscore (`__`):
+
+```css
+.ck-dialog__header
+.ck-toolbar__group
+.ck-dropdown-menu__button-collapser
+```
+
+**Modifiers** are delimited by a single underscore (`_`). Key-value modifiers
+follow the `block-or-element_key_value` naming pattern:
+
+```css
+/* Block modifier */
+.ck-dialog_hidden
+/* Element modifier */
+.ck-toolbar__group_collapsed
+/* Block modifier as key_value  */
+.ck-dropdown-menu_theme_some-theme
+```
+
+In HTML:
+
+```html
+<div class="ck-reset_all ck-dialog ck-dialog_theme_lark ck-dialog_visible">
+	<div class="ck-dialog__top ck-dialog__top_small">
+		<h1 class="ck-dialog__top-title">Title of the dialog</h1>
+		...
+	</div>
+	...
+</div>
+```
+
+### ID attributes
+
+HTML ID attribute naming pattern follows [CSS classes](#css-classes) naming guidelines. Each ID must begin with the `ck-` prefix and consist of dash–separated (`-`) words in lowercase:
+
+```html
+<div id="ck">...</div>
+<div id="ck-unique-div">...</div>
+<div id="ck-a-very-long-unique-identifier">...</div>
+```
+
+### File names
+
+File and directory names must follow a standard that makes their syntax easy to predict:
+
+* All lowercase.
+* Only alphanumeric characters are accepted.
+* Words are separated by dashes (`-`) ([kebab-case](https://en.wikipedia.org/wiki/Letter_case#Special_case_styles)).
+	* Code entities are considered single words, so the `DataProcessor` class is defined in the `dataprocessor.js` file.
+	* However, a test file covering for "mutations in multi-root editors": `mutations-in-multi-root-editors.js`.
+* HTML files have the `.html` extension.
+
+#### Examples
+
+* `ckeditor.js`
+* `tools.js`
+* `editor.js`
+* `dataprocessor.js`
+* `build-all.js` and `build-min.js`
+* `test-core-style-system.html`
+
+#### Standard files
+
+Widely used standard files do not obey the above rules:
+
+* `README.md`, `LICENSE.md`, `CONTRIBUTING.md`, `CHANGES.md`
+* `.gitignore` and all standard "dot-files"
+* `node_modules`

+ 6 - 0
docs/framework/guides/contributing/development-environment.md

@@ -105,6 +105,12 @@ Note: These arguments must be passed after additional `--`:
 yarn run docs --skip-api
 ```
 
+After building documentation, you can quickly start an HTTP server to serve them:
+
+```
+yarn run docs:serve
+```
+
 ## Generating content styles
 
 It is possible to generate a stylesheet containing content styles brought by all CKEditor 5 features. In order to do that, execute:

+ 1 - 1
docs/framework/guides/contributing/git-commit-message-convention.md

@@ -1,6 +1,6 @@
 ---
 category: framework-contributing
-order: 30
+order: 40
 ---
 
 # Git commit message convention

+ 1 - 1
docs/framework/guides/custom-editor-creator.md

@@ -121,7 +121,7 @@ mix( MultirootEditor, DataApiMixin );
 
 ## EditorUI class
 
-The `*EditorUI` class is the main UI class which initializes UI components (the main view and the toolbar) and sets up mechanisms like focus tracker or placeholder management. The custom `*EditorUI` class should extend the {@link module:core/editor/editorui~EditorUI base `EditorUI` class} like below:
+The `*EditorUI` class is the main UI class which initializes UI components (the main view and the toolbar) and sets up mechanisms like {@link framework/guides/deep-dive/focus-tracking#using-the-focustracker-class focus tracker} or placeholder management. The custom `*EditorUI` class should extend the {@link module:core/editor/editorui~EditorUI base `EditorUI` class} like below:
 
 ```js
 import EditorUI from '@ckeditor/ckeditor5-core/src/editor/editorui';

+ 1 - 1
docs/framework/guides/development-tools.md

@@ -72,7 +72,7 @@ Click the <b>"Inspect editor"</b> button below to attach the inspector to the ed
 
 {@snippet framework/development-tools/inspector}
 
-## Compatibility
+### Compatibility
 
 The inspector works with CKEditor 5 [v12.0.0](https://github.com/ckeditor/ckeditor5/releases/tag/v12.0.0)+.
 

+ 6 - 0
docs/umberto.json

@@ -218,6 +218,12 @@
 							"id": "features-real-time-collaboration",
 							"slug": "real-time-collaboration",
 							"order": 300
+						},
+						{
+							"name": "Annotations customization",
+							"id": "features-annotations-customization",
+							"slug": "annotations-customization",
+							"order": 400
 						}
 					]
 				},

+ 1 - 0
mrgit.json

@@ -44,6 +44,7 @@
     "@ckeditor/ckeditor5-paste-from-office": "ckeditor/ckeditor5-paste-from-office",
     "@ckeditor/ckeditor5-remove-format": "ckeditor/ckeditor5-remove-format",
     "@ckeditor/ckeditor5-restricted-editing": "ckeditor/ckeditor5-restricted-editing",
+    "@ckeditor/ckeditor5-select-all": "ckeditor/ckeditor5-select-all",
     "@ckeditor/ckeditor5-special-characters": "ckeditor/ckeditor5-special-characters",
     "@ckeditor/ckeditor5-table": "ckeditor/ckeditor5-table",
     "@ckeditor/ckeditor5-theme-lark": "ckeditor/ckeditor5-theme-lark",

+ 8 - 5
package.json

@@ -62,6 +62,7 @@
     "@ckeditor/ckeditor5-paste-from-office": "^18.0.0",
     "@ckeditor/ckeditor5-remove-format": "^18.0.0",
     "@ckeditor/ckeditor5-restricted-editing": "^18.0.0",
+    "@ckeditor/ckeditor5-select-all": "^0.0.1",
     "@ckeditor/ckeditor5-special-characters": "^18.0.0",
     "@ckeditor/ckeditor5-table": "^18.0.0",
     "@ckeditor/ckeditor5-theme-lark": "^18.0.0",
@@ -76,11 +77,11 @@
   },
   "devDependencies": {
     "@ckeditor/ckeditor5-comments": "^18.0.0",
-    "@ckeditor/ckeditor5-dev-docs": "^11.0.9",
-    "@ckeditor/ckeditor5-dev-env": "^17.0.0",
-    "@ckeditor/ckeditor5-dev-tests": "^18.0.0",
-    "@ckeditor/ckeditor5-dev-utils": "^12.0.5",
-    "@ckeditor/ckeditor5-dev-webpack-plugin": "^8.0.5",
+    "@ckeditor/ckeditor5-dev-docs": "^11.1.0",
+    "@ckeditor/ckeditor5-dev-env": "^18.0.0",
+    "@ckeditor/ckeditor5-dev-tests": "^19.0.0",
+    "@ckeditor/ckeditor5-dev-utils": "^13.0.0",
+    "@ckeditor/ckeditor5-dev-webpack-plugin": "^9.0.0",
     "@ckeditor/ckeditor5-inspector": "^2.0.0",
     "@ckeditor/ckeditor5-react": "^1.1.3",
     "@ckeditor/ckeditor5-real-time-collaboration": "^18.0.0",
@@ -91,6 +92,7 @@
     "eslint": "^5.5.0",
     "eslint-config-ckeditor5": "^2.0.0",
     "glob": "^7.1.2",
+    "http-server": "^0.12.1",
     "husky": "^1.3.1",
     "lint-staged": "^7.0.0",
     "mini-css-extract-plugin": "^0.4.0",
@@ -135,6 +137,7 @@
     "docs:build-and-publish": "node ./scripts/docs/build-and-publish.js",
     "docs:build-and-publish-nightly": "node ./scripts/docs/build-and-publish-nightly.js",
     "docs:content-styles": "node ./scripts/docs/build-content-styles.js",
+    "docs:serve": "http-server ./build/docs/",
     "translations:collect": "ckeditor5-dev-env-translations collect",
     "translations:download": "ckeditor5-dev-env-translations download",
     "translations:upload": "ckeditor5-dev-env-translations upload",

+ 5 - 2
scripts/docs/snippetadapter.js

@@ -275,7 +275,10 @@ function getWebpackConfig( snippets, config ) {
 		definitions[ definitionKey ] = JSON.stringify( config.definitions[ definitionKey ] );
 	}
 
-	const ckeditorWebpackPluginOptions = {};
+	const ckeditorWebpackPluginOptions = {
+		// All translation files are added to HTML files directly later.
+		buildAllTranslationsToSeparateFiles: true
+	};
 
 	if ( config.language === MULTI_LANGUAGE ) {
 		const additionalLanguages = new Set();
@@ -331,7 +334,7 @@ function getWebpackConfig( snippets, config ) {
 			} ),
 			new webpack.DefinePlugin( definitions ),
 			new ProgressBarPlugin( {
-				format: `Building snippets for language "${ config.language }": :percent (:msg)`,
+				format: `Building snippets for language "${ config.language }": :percent (:msg)`
 			} )
 		],
 

Разница между файлами не показана из-за своего большого размера
+ 252 - 234
yarn.lock


Некоторые файлы не были показаны из-за большого количества измененных файлов